electronic lead screw

[ttabbal]

How should I go about troubleshooting? Thanks in advance for your advice.

Well, that's a wild ride for sure. I think the best thing to do here is start at the beginning. I think the board is working if you have the breakpoint hitting. So at least we have a good idea that the launchpad board itself and the onboard programmer work. I would remove anything connected to it and run via USB for a bit while sorting things out. You will need to set the power jumpers to the default positions to power the board from USB.

From there, use one of the launchpad board examples that come with the IDE and make sure you can do a build/flash/run with known good setup. Something super simple like blink an LED is plenty. Flash it to the Launchpad, not just run from memory. We want to check that part of the board/chip as well.

If that works, triple check all the jumpers and switches. I don't think they are necessary for the display board to work, but it's a good place to start. Set them as directed by Clough42. From here, you can connect the PCB from him for power and interfacing. Tripple check that it's lined up properly. It CAN be installed one pin off, for example. Disconnect everything else though. Now check with the existing program for the LED blink or whatever. We want to be sure the Launchpad is getting power and working still.

Now add the display board. How are you wiring it? I found that how it's connected matters a great deal and it's pretty easy to get interference and mess up the display etc.. It doesn't damage anything, but it also doesn't work right. Start with short jumper wires direct to the interface board. No more than 6" or so. If that works, we can start looking at wiring.

With electronics/programming, troubleshooting is usually start from the simplest setup and build up one part at a time until it breaks. Now you know what is wrong and can look at fixing it. Lets get the display working and we can start on the mechanical bits.

 

[luxige]

I recommend starting from Square 1. You've reinstalled Code Composer, good. Next, download Clough42's version that you know works, and don't mess with it. Build it, flash it to the board, and see if you at least get the display working again. If you have any problems, go back and carefully follow his video, which steps through the entire build process. Once it's back up and running, then you can go in and change the constants to match your setup. Save off a copy of that.

ONLY THEN should you consider making additional changes. It's unlikely you broke anything permanently (assuming that you aren't leaving something out of the story!).

Thanks for your input!
I have followed through the video carefully, step by step, many times. It's an old friend/nemesis at this point. I'll continue to refer to it as I keep working on this, though.

I'll follow your advice about trying a known good code.

Thinking back on it, there is one more detail that may apply - I had some trouble desoldering the top-mounted header pins. Maybe I damaged the board. If it's something that simple, would that prevent the controller and peripherals from working? (When I turn the rotary encoder shaft, there is no response from the servo).

 

[luxige]

This is always an annoying situation. There are so many components that it is difficult to diagnose the cause of the failure. When I bought my display board, I bought an extra. Fortunately, both worked. Is it possible for you to connect it to an Arduino? This would parse out the display from the rest of the system. It is possible that there is a problem with one of the other boards. ESD would be a likely culprit. Also double check that the switches are all set correctly and that wiring is correct.

I doubt that the encoder or the stepper controller outputs are at fault. The problem would either be the display itself or the Launchpad from a hardware standpoint or from the Code composer or firmware. Perhaps contacting Clough is in order. He may have some suggestions.

Thanks for your reply!
I don't have any means to test the display board separately. I may have damaged it when I desoldered the stock header pins, see my reply above to kb58.

I was pretty careful about static mitigation. But, who knows? I am sure the little switches are properly set, but of course I will be rechecking that and everything else. My first step will be to check all my cables/connectors for continuity. And verify I didn't switch a pin.

I will open an issue on Github and send an email to James.

 

[luxige]

Well, that's a wild ride for sure. I think the best thing to do here is start at the beginning. I think the board is working if you have the breakpoint hitting. So at least we have a good idea that the launchpad board itself and the onboard programmer work. I would remove anything connected to it and run via USB for a bit while sorting things out. You will need to set the power jumpers to the default positions to power the board from USB.

From there, use one of the launchpad board examples that come with the IDE and make sure you can do a build/flash/run with known good setup. Something super simple like blink an LED is plenty. Flash it to the Launchpad, not just run from memory. We want to check that part of the board/chip as well.

If that works, triple check all the jumpers and switches. I don't think they are necessary for the display board to work, but it's a good place to start. Set them as directed by Clough42. From here, you can connect the PCB from him for power and interfacing. Tripple check that it's lined up properly. It CAN be installed one pin off, for example. Disconnect everything else though. Now check with the existing program for the LED blink or whatever. We want to be sure the Launchpad is getting power and working still.

Now add the display board. How are you wiring it? I found that how it's connected matters a great deal and it's pretty easy to get interference and mess up the display etc.. It doesn't damage anything, but it also doesn't work right. Start with short jumper wires direct to the interface board. No more than 6" or so. If that works, we can start looking at wiring.

With electronics/programming, troubleshooting is usually start from the simplest setup and build up one part at a time until it breaks. Now you know what is wrong and can look at fixing it. Lets get the display working and we can start on the mechanical bits.

Thanks for your advice, that's very helpful and clear!
I think that trying a sample program is a great idea. Browsing the directory, I don't see any sample program files. Where should I be looking?

Jumpers and switches are all correct, I'm sure, but of course I will recheck. I'll check all my cables as well.
the display board is connected via short sections of ribbon cable to aviation-style round connectors, with a shielded cable in between. Right now it's a bench setup, and I think I kept the noisy stuff away from the data pretty well. But I'll make up a short test cable.

As noted above, I think it's possible I damaged the display board when desoldering. Do you think that would prevent the program from responding to the rotary encoder input?

 

[ttabbal]

Thanks for your advice, that's very helpful and clear!
I think that trying a sample program is a great idea. Browsing the directory, I don't see any sample program files. Where should I be looking?

Jumpers and switches are all correct, I'm sure, but of course I will recheck. I'll check all my cables as well.
the display board is connected via short sections of ribbon cable to aviation-style round connectors, with a shielded cable in between. Right now it's a bench setup, and I think I kept the noisy stuff away from the data pretty well. But I'll make up a short test cable.

As noted above, I think it's possible I damaged the display board when desoldering. Do you think that would prevent the program from responding to the rotary encoder input?

It looks like the installer defaults to C:\ti\tutorial.

There is some documentation here that might be helpful getting things going. http://www.ti.com/lit/an/spra766/spra766.pdf?ts=1590694503172

I wouldn't think that damaging the solder pads would mess up the ability to run the encoder and servo. Though it's hard to debug issues with those without the screen. You might be able to run connected to the debugger and use breakpoints to see the changes in the encoder. The trick here is that a single wire mixed up can make it not respond, but you have no way to see that. At least with the display, you can see the RPM change, so you know the encoder is good, for example.

I doubt you damaged the display board too badly. If you can post some pics of the setup I might be able to see something to investigate further. If you don't have a backup display board, it might be a good idea to get one. Those are cheap at least. If you don't have the experience soldering, I could probably mod one of mine for you. Desoldering headers is a pain. Do try with a test setup though. Even just jumper wires breadboard style is fine if they are short.

 

[luxige]

It looks like the installer defaults to C:\ti\tutorial.

There is some documentation here that might be helpful getting things going. http://www.ti.com/lit/an/spra766/spra766.pdf?ts=1590694503172

I wouldn't think that damaging the solder pads would mess up the ability to run the encoder and servo. Though it's hard to debug issues with those without the screen. You might be able to run connected to the debugger and use breakpoints to see the changes in the encoder. The trick here is that a single wire mixed up can make it not respond, but you have no way to see that. At least with the display, you can see the RPM change, so you know the encoder is good, for example.

I doubt you damaged the display board too badly. If you can post some pics of the setup I might be able to see something to investigate further. If you don't have a backup display board, it might be a good idea to get one. Those are cheap at least. If you don't have the experience soldering, I could probably mod one of mine for you. Desoldering headers is a pain. Do try with a test setup though. Even just jumper wires breadboard style is fine if they are short.

Thank you, Travis!
A new display board is on the way. I'll connect to the stock pins at first to eliminate that variable.
I don't think I'll need to take you up on your generous offer of a board, but thanks very much.

The article you linked to looks interesting, though most of it is over my head. I think I could stumble through the tutorial if I had it, but it's not in my install. C:\ti only contains one folder, \ccs1000, which only contains \ccs and \xdctools_3_61_00_16_core.
One thing I failed to mention before is that this is v10 of CCS, the only version I saw on the TI wesite. That may be why I had to update the XDS110 firmware to get the code to flash.

I'll report back when I recheck all the cables, etc. Might be a day or two, I need a break!

 

[ttabbal]

Good luck! Sometimes taking a break is the best way to clear your mind. I've even thought up solutions while away from the computer.

 

[GunsOfNavarone]

I tried to read this whole thread...but its huge. It started to touch on this, but no real answer.
If I were to build something CNC...leadscrew, X axis, whatever....and I built the system off Arduino, would this work with Fusion360 or Mach 3? Does it work with the G code the design software generates? Or do I need to work with an entirely different controller? Can some short and dirty explain the controlling aspect of a CNC device? I'm very close to just buying enough to do one unit to see how much work it would be to covert my mill or (more likely) my lathe.

 

[ttabbal]

Gcode is pretty simple, it really amounts to move X 10mm type stuff. What the electronic leadscrew tries to do is a bit different. It's to sync the spindle with carriage movement at a fixed rate. That's why we can thread with it. I suspect you would need similar control for CNC conversion, but that's not what we're looking for with this. What we are doing is replacing the gearbox or change gears with electronic versions.

Mach and linuxcnc seem to be the brain box, no need for microcontrollers. Though it might be useful for reading the encoder, for example. But the computer directly controls the motion system. These take the gcode and generate the pulses to move the motors around.

Fusion360 generates gcode using the CAM module. It's a step above the motion system. It's a different type of software.

 

[GunsOfNavarone]

@ttabbal I wanted to avoid the ELS as there is more involved...timing one type of motion with another. What I need (or at least, really WANT to understand) is design software creates G-code, what does that go to, then what does that go to, and so on. It SEEMS like, depending how you want to do this, the hardware can vary.
I'd like to know WHAT I'm shopping for and why.