He reduced the micro-stepping on his motors, thereby doubling the speed, and adjusted the code accordingly. That would've been the *first* thing I tried. I get the impression he didn't understand until late in the thread that was possible.
Jason...you are wrong. I did not reduce the micro-stepping on the motors. I did understand that there was an alternative to driving the steppers but it would reduce the machine capability somewhat compared to using the SD memory. I wanted to give you every opportunity to get the SD memory approach working. The code does not work so, I implemented the alternative. If there is a way to get your code functioning...I will consider a second upgrade.
I wanted to give you every opportunity to get the SD memory approach working. The code does not work so, I implemented the alternative.
Discovery, what was the alternative solution that you implemented, and why didn't the SD memory approach work? I've spent much less time on this than Jason did, but I feel like I need to understand what went wrong here.
Dave...The previous stepper motors used on the plasma cutting machine required four phase signals to rotate the armatures and could not spin fast enough to provide the cutting speed to handle materials from 5/8 inch thick steel, aluminum, stainless steel down to 22 gauge. I removed the algorithms from my "C" program that formed the x-axis and y-axis phases and output only the step and direction signals to the two high speed stepper motors. My printed circuit control board needed a simple modification to switch from four phase output to step and direction outputs.
I do not know why Jason's code did not output the memory data on the propeller pins (0,1,2,3). I added some simple data handler code just before Jason's code that wrote 1,000 words into the SD memory then read out the 1,000 words sending them to the computer screen for display and verification. Immediately after reading the SD memory and sending the data to the screen, Jason's program ran but produced only his activity monitor on the screen...one line (0123). There was no output on the four propeller pins. I am not an expert "C" programmer and cannot tell you why there is no output.
It seems Discovery's understanding of the Clearpath motors is incorrect. They are not stepper motors, but DC (BLDC?) servomotors with an integrated encoder and circuitry to mimic a stepper by just having a STEP and DIRECTION input. Just like steppers, they can get "behind" temporarily, but will not lose step pulses. True steppers of course once they get "behind" at high speed are totally lost, and typically not recoverable without re-ramping up to high speed; an obvious disaster for a CNC application.
The Clearpath motors are a great choice here as they will recover if you over-speed them.
I have no idea as to why he insists on doing things in this particular brute force way as there seem to be much better approaches. Probably his smart board really don't get it.
Even if the motors can catch up, they won't maintain synchronization if you're over-speeding two of them simultaneously. If I send the pulses to produce a circle 4x faster than the motors can move, at some point the motors are just going to be running a straight-line path to the commanded end-point, are they not?
If he previously used unipolar steppers that would explain the need to output 4 distinct output lines per motor. Switching to a step/dir system and different motors with motor drivers would be trivial. Changing the gearing, if possible, would be an additional option.
My own CNC machine uses traditional steppers and is capable of 2000 ipm (33 inches/sec) with a resolution of 0.0005". I would expect that would be more than fast and accurate enough for a plasma cutter, which, if I understand correctly, has a typical cut tolerance of about 0.02". The plasma cutting head would weigh dramatically less than a spindle, so you don't need the kind of torque you need for a CNC and would be able to push it much faster.
I'm not convinced there is "a board", or that they or Discovery have any idea what they're doing. I'm going to test my code this weekend to prove to myself that it does exactly what I say it does, because I'm pretty sure the problem isn't the code, either.
Your system sound incredible to me. At 2000 inches per minute with 2000 steps per inch (at least that is what I'm interpreting from your .0005 inch resolution), that's 4,000,000 steps per minute, or 66,666 steps per second. That must be some motor/controller combination. Much faster than I can do.
It's PC/Mach3 based, so it's got some oomph. Steps per inch is actually 1908.17...? I also never actually run it at 2K ipm, that's just what the upper-end of the envelope is. I rarely run it higher than 1200ipm for rapids, occasionally 1500 if the job has lots of long moves. You can't cut that fast, and acceleration is generally the limiting factor for short moves because there's a lot of mass.
This is the code I posted to the forums, playing a data file I generated with a quick C# app I wrote. The Propeller is clocking out 4 pins of step/direction data as 53,000 steps/second, compiled in CMM mode.
Jason...You state above that the program you wrote in C++ compiled in CMM mode works fine. I do not disagree but as you very well know, I could not get your C++ code to compile.
I asked for C code rather than C++ code and your modified C++ to C code is the problem. It does not work. Computer experts were not able to save your C++ code in SimpleIDE as a .cpp extension. It always saved as a .cpp.c extension.
I did not ask anyone for a critique of my company's machine design. I stated that I was able to store data words into the SD memory but when I read the data and sent it to propeller pins p0, p1, p2, and p3. The data was excellent but the output data rate was too slow so I asked if it was possible to make the SD memory into a FIFO and clock the data out at a much faster rate approaching the speed of the SD memory. The answer was yes and I received a C++ program that I am not able to use. The C program you sent does not work.
Discovery: The C code posted to the forum on the previous page (March 28th) is what is being demonstrated here, not the C++ version. I'm guessing that in your well-demonstrated impatience you missed it, but it's still there. To be sure I hadn't changed anything, I downloaded that code directly from the forum for the test. It's the message before your "Just got back" post on Apr 2nd.
Jason...Great to hear that the C++ version of SDTest was converted to C and posted on March 28th is the code you demonstrated. I must have an error in the code since it will not compile. I will check that code again...must have missed something.
Excuse me...What I meant to say is that the C code for SDTest does compile but I get no output. I will check the code again. I must have made an error somewhere.
It burns through the data pretty fast at 53000 bytes / sec. My file was several Mb, not 1000 bytes. When it's done reading it just stops, so it would be very easy to miss if you don't have much data.
Excuse me...What I meant to say is that the C code for SDTest does compile but I get no output. I will check the code again. I must have made an error somewhere.
Discovery
Just a side note, I copy and pasted the .c file into Simple IDE and hit the build button and it reported the build successful. (Not sure how to get Simple IDE to open a .C file with out copy and pasting into notepad)
I don't have it in C. I wrote an application in C# to generate the file on my PC, mounted the SD card, and copied the file to it. If you are opening the file for writing, use:
file = fopen( "filename.ext", "wb" );
If you are omitting the 'b' after the 'w' you'll be opening the file for writing as text, and zero characters will be treated as end-of-file markers.
I tried to attach the file I generated, but at 4.8mb, it's too large to post in the forums.
Jason...that is the instruction that I use; however, there are other instructions in the writing code that carry bit width and other stuff that may be the problem.
file = fopen( "filename.ext", "wb" );
There is a lesson in Parallax that shows how to write and read data into and out of the SD memory. That is the code that I am using. So, there appears to be a data mismatch.
Their example is writing text, which omits the 'b' character (binary) from the fopen( ...., "wb" ) command.
fopen( "filename", "w" ) is how you open a text file for writing.
fopen( "filename", "wb" ) is how you open a binary file for writing.
They're different. Are you using the first version or the second one? How much data are you writing into the file? How do you know it doesn't get output? Do you have a capture scope, or are you just hoping to see the machine move, or an LED blink or something?
Jason...When I said works fine, I mean that when I read the values out to the screen, it works fine. When I detect the output from the memory for 1's and 0's I set p0 high and low to generate a clock that drives the stepper motor for test and it works fine.
Jason...Yes, I can post the code; however, a more immediate task has taken top priority. My new dish washer is a few months out of warranty and it is flooding the kitchen floor.
I recommend that you run the Parallax/learn/sd memory file since it is what I used. I added a single dimension array of 1000 entries then wrote alternate 1's and 0's into the array. Following that I wrote the array to the SD memory using the wb extension. Following that I read the SD memory using the rb extension and printed the data to the screen. There was a perfect match.
Next, I added some compare instructions: if the SD memory word was a 1 I set the p0 to high and if the SD memory word was 0 I set the p0 to low. The result was a perfect clock that I used to drive the ClearPath motor.
Next, I copied the instructions for writing the 1's and 0's pattern to the SD memory into your SDTest program thinking that the data should show up on the p0 pin also attached to the scope and the ClearPath motor.
Re: the dishwasher. If the source of the leak is not readily apparent check the clamps on the hoses interconnecting the pump and solenoids. Found the hose clamps the manufacturer was using were of such poor quality and low clamping force that water was coming out whenever the pump was draining the tub.
These are ODT files, not .c files. It's as though you copied the text from SimpleIDE into your favorite text editor and then posted the result. Please just attach the .c files directly.
Comments
Discovery
I do not know why Jason's code did not output the memory data on the propeller pins (0,1,2,3). I added some simple data handler code just before Jason's code that wrote 1,000 words into the SD memory then read out the 1,000 words sending them to the computer screen for display and verification. Immediately after reading the SD memory and sending the data to the screen, Jason's program ran but produced only his activity monitor on the screen...one line (0123). There was no output on the four propeller pins. I am not an expert "C" programmer and cannot tell you why there is no output.
Discovery
It seems Discovery's understanding of the Clearpath motors is incorrect. They are not stepper motors, but DC (BLDC?) servomotors with an integrated encoder and circuitry to mimic a stepper by just having a STEP and DIRECTION input. Just like steppers, they can get "behind" temporarily, but will not lose step pulses. True steppers of course once they get "behind" at high speed are totally lost, and typically not recoverable without re-ramping up to high speed; an obvious disaster for a CNC application.
The Clearpath motors are a great choice here as they will recover if you over-speed them.
I have no idea as to why he insists on doing things in this particular brute force way as there seem to be much better approaches. Probably his smart board really don't get it.
Cheers,
Peter (pjv)
If he previously used unipolar steppers that would explain the need to output 4 distinct output lines per motor. Switching to a step/dir system and different motors with motor drivers would be trivial. Changing the gearing, if possible, would be an additional option.
My own CNC machine uses traditional steppers and is capable of 2000 ipm (33 inches/sec) with a resolution of 0.0005". I would expect that would be more than fast and accurate enough for a plasma cutter, which, if I understand correctly, has a typical cut tolerance of about 0.02". The plasma cutting head would weigh dramatically less than a spindle, so you don't need the kind of torque you need for a CNC and would be able to push it much faster.
I'm not convinced there is "a board", or that they or Discovery have any idea what they're doing. I'm going to test my code this weekend to prove to myself that it does exactly what I say it does, because I'm pretty sure the problem isn't the code, either.
Your system sound incredible to me. At 2000 inches per minute with 2000 steps per inch (at least that is what I'm interpreting from your .0005 inch resolution), that's 4,000,000 steps per minute, or 66,666 steps per second. That must be some motor/controller combination. Much faster than I can do.
Good on you!
Cheers,
Peter (pjv)
I asked for C code rather than C++ code and your modified C++ to C code is the problem. It does not work. Computer experts were not able to save your C++ code in SimpleIDE as a .cpp extension. It always saved as a .cpp.c extension.
I did not ask anyone for a critique of my company's machine design. I stated that I was able to store data words into the SD memory but when I read the data and sent it to propeller pins p0, p1, p2, and p3. The data was excellent but the output data rate was too slow so I asked if it was possible to make the SD memory into a FIFO and clock the data out at a much faster rate approaching the speed of the SD memory. The answer was yes and I received a C++ program that I am not able to use. The C program you sent does not work.
Discovery
Discovery
Discovery
Just a side note, I copy and pasted the .c file into Simple IDE and hit the build button and it reported the build successful. (Not sure how to get Simple IDE to open a .C file with out copy and pasting into notepad)
Could I prevail upon you to send the code you use to write data to the SD Memory? In C please>
That should clear up the problem.
Sincerely,
Discovery
If you are omitting the 'b' after the 'w' you'll be opening the file for writing as text, and zero characters will be treated as end-of-file markers.
I tried to attach the file I generated, but at 4.8mb, it's too large to post in the forums.
file = fopen( "filename.ext", "wb" );
There is a lesson in Parallax that shows how to write and read data into and out of the SD memory. That is the code that I am using. So, there appears to be a data mismatch.
Discovery
http://learn.parallax.com/tutorials/language/propeller-c/propeller-c-simple-devices/sd-card-data
(if not, can you post a link to the page you're referring to so I can see what you're working from?)
Their example is writing text, which omits the 'b' character (binary) from the fopen( ...., "wb" ) command.
fopen( "filename", "w" ) is how you open a text file for writing.
fopen( "filename", "wb" ) is how you open a binary file for writing.
They're different. Are you using the first version or the second one? How much data are you writing into the file? How do you know it doesn't get output? Do you have a capture scope, or are you just hoping to see the machine move, or an LED blink or something?
I am not sure about the version.
1000 words of different values: 1's and 0's in the p0 output to generate a clock. works fine. All words set to 15 to drive all bits high.
I have a four channel digital scope monitoring all four outputs.
It is set for capture.
Discovery
Discovery
+1
I got a good laugh out of that demonstration
I recommend that you run the Parallax/learn/sd memory file since it is what I used. I added a single dimension array of 1000 entries then wrote alternate 1's and 0's into the array. Following that I wrote the array to the SD memory using the wb extension. Following that I read the SD memory using the rb extension and printed the data to the screen. There was a perfect match.
Next, I added some compare instructions: if the SD memory word was a 1 I set the p0 to high and if the SD memory word was 0 I set the p0 to low. The result was a perfect clock that I used to drive the ClearPath motor.
Next, I copied the instructions for writing the 1's and 0's pattern to the SD memory into your SDTest program thinking that the data should show up on the p0 pin also attached to the scope and the ClearPath motor.
Hopefully later today I can post the files.
Discovery
Discovery
Re: the dishwasher. If the source of the leak is not readily apparent check the clamps on the hoses interconnecting the pump and solenoids. Found the hose clamps the manufacturer was using were of such poor quality and low clamping force that water was coming out whenever the pump was draining the tub.
Discovery
Discovery