I am now definitely getting printouts of H + L, but the pin numbers are incorrect. With an input of G1 X10 Y15, it is showing PIN#s 1, 5, 0, and 4. I would imagine that 1 and 5 are setting the direction of the drivers, since they only appear once and at the beginning of the output, and the numbers 0 and 4 must be the step pulses, because they occur numerous times. However, I have modified the step and direction pins for both X and Y in config.h as follows:
// X Pinouts and defines
#define X_DIR_PIN 22 //Forger
#define X_STEP_PIN 23 //Forger
// Y Pinouts and defines
#define Y_STEP_PIN 26 //Forger
#define Y_DIR_PIN 27 //Forger
If we can get the X and Y actuators to move, that would be a sight to see.
The pin numbers are undef'ed in simulator.h, and then redefined in an enum. The attached simulator.h has the pin numbers you specified. Copy that to your build. I'll have to try enabling LOOKAHEAD to see what happens.
For some odd reason, LOOKAHEAD worked fine after the first time. I don't understand why.
Anyhow.... I just tried it with the actuators and either the pulse is not reaching the drivers or the timing is off. These drivers require a minimum high pulse width of 1uS. Is there anyway to set that properly?
simulator.h undef's the READ, WRITE, SET_INPUT and SET_OUTPUT macros, and they are replaced by functions with the same name in simulator/simulator.c. You just need to add a line to each function to make it talk to the pins correctly.
The changes look good. Can you monitor the pins to see if they are wiggling? Maybe SET_OUTPUT was never called. Oh no, I think I just realized what the problem may be. Since the code is running on two cogs the I/O is coming from two cogs also. I'll have to think about this for a while. We need to make sure that all the I/O for a pin is only coming from one cog.
Pertaining to the wiggle of the pins..... There is definitely no wiggle. There is a distinct sound of the drivers locking in, when a signal has been achieved. More or less the motors locking into position.
Try adding SET_OUTPUT calls to the timer_cog function in simulator/timer_ext.c. If this doesn't work there may be a conflict with calling SET_OUTPUT from the main cog. You will either need to disable the SET_OUTPUT calls in the main cog, or change the code in the SET_OUTPUT routine so it returns if the cogid is 0.
void timer_cog(void *par)
{
SET_OUTPUT(X_DIR_PIN);
SET_OUTPUT(Y_DIR_PIN);
SET_OUTPUT(X_STEP_PIN);
SET_OUTPUT(Y_STEP_PIN);
while (1)
{
if (cnt64() >= target_cycles)
{
target_cycles = -1;
while (lockset(locknum));
timer1_isr();
lockclr(locknum);
}
}
}
If this doesn't work there may be a conflict with calling SET_OUTPUT from the main cog. You will either need to disable the SET_OUTPUT calls in the main cog,
That is where I am at in the my code. I have moved all pin setting operations to queue_monitor.c, which finally gave me the "wiggle" you were referring to.
That seemed to speed things up a bit, but still very slow. Additionally, I tried altering the values in config.h, but did not seem to affect it much.
One other item worth mention, is that it seems to lose track of the concept of distance from one move to the next, but I could be wrong about that. There were a couple of times when I entered G1 commands and no movement occured.
I added a few debug prints to try to figure out why the stepper is running slowly. I think the problem is that the code running under the CMM model is running too slow to keep up with the timer requests. This causes the simulated 16-bit AVR counter to wrap, which results in a longer time delay to be computed. I changed TICK_TIME to 2 MS, and F_CPU to 1 million. I found that the timer code couldn't keep up with the 2 MS interrupt time. I changed TICK_TIME to 5 MS and determined that the timer code was taking 3 MS to run.
The timer code is extremely simple, so it's surprising that it takes 3 MS to run. The stepper code is a more complex, so it probably takes even longer to run. It seems odd that an AVR can run faster than a Prop, but this may be the case when the Prop is running the CMM model. Under CMM, we're probably getting only about 1 MIPS out of a cog.
The timer code may have to be run using the COG model for it to keep up. However, it's doubtful that all the timer code will fit in a COG. It's probably doable, but it looks like a big effort to get it to fit.
It's probably doable, but it looks like a big effort to get it to fit.
Considering there are other options, it isn't worth any more effort, but I certainly appreciate all of your help and the effrot that you did put into it. If it wasn't for the LOOKAHEAD feature, I probably would have given up long ago. I believe that creating 3D printing frimware for the Propeller really isn't that big of a deal, but creating one with ramping and LOOKAHEAD, that is quite a different story.
I still think that simultaneous cogs running four counters is probably the best route for running the steppers, but I am not a mathematician and it would take some serious problem solving to work that all out. One thing I know for sure... When passing parameters to the counters, I can make those steppers sing. I just wish I was better at math and physics.
I was just wondering when I saw this, but is this program compatable with the Merlin firmware thats been used with the Arduino software? I have the Printrbot Simple Makers 1405 3D printer and was thinking of making a new 3D printer using my firmware and the Propeller, and was curious as to this.
I figured this would be a better place to discuss Teacup.
I am now thinking about eliminating all non-critical code that does not pertain directly to X and Y movement, which should provide some memory to troubleshoot the timer code and possible memory barrier issues.
idbruce - it's a pity that you are passing up this opportunity to have so much fun interacting with motors and mechanisms through Forth, and I do mean interacting. Debugging is a breeze and all those "what ifs" you can just turn into instant "try this" which many times reshapes your concepts of how to implement software and hardware. When we have fun learning, we learn so much better and so much more.
I am now thinking about eliminating all non-critical code that does not pertain directly to X and Y movement, which should provide some memory to troubleshoot the timer code and possible memory barrier issues.
ie result is quite large files, but a very simple playback scheme.
Borrowing a little from the broad idea of off-loading some of the more complex Calcs, you could move some of the C code to a PC-Host, and deploy a fast serial link to the controller.
The C-code can port later to either P2, or maybe P1 if there is spare resource.
I'm looking at FT4222 as a Serial host, and it has Quad SPI master/slave, so uses 4 data pins, half duplex.
Interface is SS0,CLK,Dio0..Dio3 Top speed has recently improved to 6.725MBytes/sec 53.8Mbps, above P1, but maybe P2 ?
If we use a rough number of P1 able to do ~ 3M samples/sec that's around 12 MBits/sec one way possible over the link.
(FT4222 is HS-USB, 4160 total bytes of buffer, and low cost, ~$1.53/1k so you can run to whatever speed a P1 can be crafted to hit)
Using bursts, you can focus on speed for each section, and the design I have (for a small 8b MCU) sends a burst, then has a defined idle time of some SCKs, and then replies.
The idle time is count based, so it is easy to tune and adjust, and there remains a deterministic throughput.
idbruce - it's a pity that you are passing up this opportunity to have so much fun interacting with motors and mechanisms through Forth, and I do mean interacting. Debugging is a breeze and all those "what ifs" you can just turn into instant "try this" which many times reshapes your concepts of how to implement software and hardware. When we have fun learning, we learn so much better and so much more.
I have a lot of faith in you as both a programmer and an electrical engineer, as well as your ability to grasp the entire picture of making something work well.
And yes, I agree it is a pity that I am not currently jumping at the opportunity, but that does not mean that I won't in the future. If your efforts had all been in place, when I first started with the Propeller, than most likely it would have been much easier to sway my direction at the time.
When I said " I just wish you were making your attempt in C", in no way was I trying to say or imply that C is a better language. It is just the best programming language that I currently know how to use, although I must admit, that I like it much better than Spin, but that is most due to my knowledge of C and because of the wider availability of free source code.
If I could quickly download Forth and Tachyon into my brain, I would do it without hesitation, but alas, we do not have that technology yet However, in all fairness, I will be perfectly honest with you. If I currently had the time to devote to learning new programming languages, it would most likely be in this order, ASM, PASM, Forth. I see you guys writing and speaking ASM and PASM all the time, and I really wish I understood it, but I just currently do not have the time to learn, due to time, irons in the fire, health issues, etc....
As a friend and comrade, I ask you to please not take any offense, that I am currently unable to devote time to learning any new language. I know that you have poured countless hours and devotion into your work, and there is no doubt in my mind, that it would be worth learning, if only I had the time.
You may have noticed, that I have mentioned using one of Parallax's competitors products, a couple of times, pertaining to interpolated CNC projects, but that is only due to time and priority issues within my life. Because I simply do not have the time to struggle or learn.
Please try to understand. Go Forth in peace my friend.
idbruce - I don't ever worry about which language is the "better language", it's about suitability and productivity for me and besides I've said this many times, the "language" part of Tachyon Forth is only one small part, there is a whole development/runtime environment sitting on the Prop itself.
If you do drop your shields and become assimilated by the Forth in this G-code endeavor it would be a very productive one I am very sure. While I may write code and be able to test it out to some extent, it is your practical skills and uses that will be the proving ground where the application becomes fully functional and really useful. Just think, there would be no need to wait for the day year when P2 is readily available, you can have it up and running very soon on your favorite close at hand 8-core microcontroller.
HERE is a Hackaday project where the author implements every GCODE word as a FORTH word. Fun. M17 enable motors...
@idbruce, this is not to get you to change your horse but this guy says his little interpreter is
" It looks like the GCODE interpreter is going to be about 3K of code on top of about 4.5K of eForth. Not a fancy interpreter by any means but it'll work (I believe)." Now that is some serious thought compression from a FORTH runtime. Anyway just have some fun whatever you end up doing, not that the fun always comes easy.
Comments
I am now definitely getting printouts of H + L, but the pin numbers are incorrect. With an input of G1 X10 Y15, it is showing PIN#s 1, 5, 0, and 4. I would imagine that 1 and 5 are setting the direction of the drivers, since they only appear once and at the beginning of the output, and the numbers 0 and 4 must be the step pulses, because they occur numerous times. However, I have modified the step and direction pins for both X and Y in config.h as follows:
If we can get the X and Y actuators to move, that would be a sight to see.
Another item worth noting.... If you enable LOOKAHEAD in config.h, it acts like the Enegenizer bunny... It just keeps going and going and going
EDIT: After my post, it stopped.
For some odd reason, LOOKAHEAD worked fine after the first time. I don't understand why.
Anyhow.... I just tried it with the actuators and either the pulse is not reaching the drivers or the timing is off. These drivers require a minimum high pulse width of 1uS. Is there anyway to set that properly?
I hate to keep bothering you with this, but you know the simulator code well. I still have no movement, and here is how I added them:
bool READ(pin_t pin) { sim_assert(pin < PIN_NB, "READ: Pin number out of range"); // Add any necessary reactive pin-handlers here. //return state[pin]; return (INA >> pin) & 1; } void WRITE(pin_t pin, bool s) { bool old_state = state[pin]; uint64_t nseconds = sim_runtime_ns(); sim_assert(pin < PIN_NB, "WRITE: Pin number out of range"); if (s) OUTA |= (1 << pin); else OUTA &= ~(1 << pin); if (direction[pin] == out) { state[pin] = s; } if (old_state != s) { #ifdef TRACE_ALL_PINS fgreen(); for (int i = 0; i < PIN_NB; i++) { if (state[i]) bred(); else bblack(); fputc('A' + i, stdout); } fbreset(); printf("\n"); #else bred(); if (s) sim_tick('A' + pin); else sim_tick('a' + pin); fbreset(); #endif } if (s && !old_state) { /* rising edge */ int axis = AXIS_NONE; int dir; switch (pin) { case X_STEP_PIN: dir = state[X_DIR_PIN] ? 1 : -1; #ifdef X_INVERT_DIR dir = -dir; #endif axis = X_AXIS; break; case Y_STEP_PIN: dir = state[Y_DIR_PIN] ? 1 : -1; #ifdef Y_INVERT_DIR dir = -dir; #endif axis = Y_AXIS; break; case Z_STEP_PIN: dir = state[Z_DIR_PIN] ? 1 : -1; #ifdef Z_INVERT_DIR dir = -dir; #endif axis = Z_AXIS; break; case E_STEP_PIN: dir = state[E_DIR_PIN] ? 1 : -1; #ifdef E_INVERT_DIR dir = -dir; #endif axis = E_AXIS; break; default: break; } if ( axis != AXIS_NONE ) { pos[axis] += dir; print_pos(); } } } void SET_OUTPUT(pin_t pin) { sim_assert(pin < PIN_NB, "Pin number out of range"); direction[pin] = out; DIRA |= (1 << pin); } void SET_INPUT(pin_t pin) { sim_assert(pin < PIN_NB, "Pin number out of range"); direction[pin] = in; DIRA &= ~(1 << pin); }Source: Teacup FirmwareYou know if you pull this off....
Considering all the trouble of converting all the AVR stuff to the Propeller...
There will be Teacup fans around the world attempting to convert your code
Pertaining to the wiggle of the pins..... There is definitely no wiggle. There is a distinct sound of the drivers locking in, when a signal has been achieved. More or less the motors locking into position.
void timer_cog(void *par) { SET_OUTPUT(X_DIR_PIN); SET_OUTPUT(Y_DIR_PIN); SET_OUTPUT(X_STEP_PIN); SET_OUTPUT(Y_STEP_PIN); while (1) { if (cnt64() >= target_cycles) { target_cycles = -1; while (lockset(locknum)); timer1_isr(); lockclr(locknum); } } }That is where I am at in the my code. I have moved all pin setting operations to queue_monitor.c, which finally gave me the "wiggle" you were referring to.
SUCCESS!!!! You have achieved movement on both axes
It is as sssssslllllllllllllooooooooowwwwwwww as molassis in January, but you are definitely on to something.
One other item worth mention, is that it seems to lose track of the concept of distance from one move to the next, but I could be wrong about that. There were a couple of times when I entered G1 commands and no movement occured.
The timer code is extremely simple, so it's surprising that it takes 3 MS to run. The stepper code is a more complex, so it probably takes even longer to run. It seems odd that an AVR can run faster than a Prop, but this may be the case when the Prop is running the CMM model. Under CMM, we're probably getting only about 1 MIPS out of a cog.
The timer code may have to be run using the COG model for it to keep up. However, it's doubtful that all the timer code will fit in a COG. It's probably doable, but it looks like a big effort to get it to fit.
Considering there are other options, it isn't worth any more effort, but I certainly appreciate all of your help and the effrot that you did put into it. If it wasn't for the LOOKAHEAD feature, I probably would have given up long ago. I believe that creating 3D printing frimware for the Propeller really isn't that big of a deal, but creating one with ramping and LOOKAHEAD, that is quite a different story.
I still think that simultaneous cogs running four counters is probably the best route for running the steppers, but I am not a mathematician and it would take some serious problem solving to work that all out. One thing I know for sure... When passing parameters to the counters, I can make those steppers sing. I just wish I was better at math and physics.
Thanks Dave
Bruce
Joe
I figured this would be a better place to discuss Teacup.
I am now thinking about eliminating all non-critical code that does not pertain directly to X and Y movement, which should provide some memory to troubleshoot the timer code and possible memory barrier issues.
There was an earlier thread about NC control treated as a Stepper-pattern-playback-problem.
ie result is quite large files, but a very simple playback scheme.
Borrowing a little from the broad idea of off-loading some of the more complex Calcs, you could move some of the C code to a PC-Host, and deploy a fast serial link to the controller.
The C-code can port later to either P2, or maybe P1 if there is spare resource.
I'm looking at FT4222 as a Serial host, and it has Quad SPI master/slave, so uses 4 data pins, half duplex.
Interface is SS0,CLK,Dio0..Dio3 Top speed has recently improved to 6.725MBytes/sec 53.8Mbps, above P1, but maybe P2 ?
If we use a rough number of P1 able to do ~ 3M samples/sec that's around 12 MBits/sec one way possible over the link.
(FT4222 is HS-USB, 4160 total bytes of buffer, and low cost, ~$1.53/1k so you can run to whatever speed a P1 can be crafted to hit)
Using bursts, you can focus on speed for each section, and the design I have (for a small 8b MCU) sends a burst, then has a defined idle time of some SCKs, and then replies.
The idle time is count based, so it is easy to tune and adjust, and there remains a deterministic throughput.
I have a lot of faith in you as both a programmer and an electrical engineer, as well as your ability to grasp the entire picture of making something work well.
And yes, I agree it is a pity that I am not currently jumping at the opportunity, but that does not mean that I won't in the future. If your efforts had all been in place, when I first started with the Propeller, than most likely it would have been much easier to sway my direction at the time.
When I said " I just wish you were making your attempt in C", in no way was I trying to say or imply that C is a better language. It is just the best programming language that I currently know how to use, although I must admit, that I like it much better than Spin, but that is most due to my knowledge of C and because of the wider availability of free source code.
If I could quickly download Forth and Tachyon into my brain, I would do it without hesitation, but alas, we do not have that technology yet
As a friend and comrade, I ask you to please not take any offense, that I am currently unable to devote time to learning any new language. I know that you have poured countless hours and devotion into your work, and there is no doubt in my mind, that it would be worth learning, if only I had the time.
You may have noticed, that I have mentioned using one of Parallax's competitors products, a couple of times, pertaining to interpolated CNC projects, but that is only due to time and priority issues within my life. Because I simply do not have the time to struggle or learn.
Please try to understand. Go Forth in peace my friend.
Bruce
If you do drop your shields and become assimilated by the Forth in this G-code endeavor it would be a very productive one I am very sure. While I may write code and be able to test it out to some extent, it is your practical skills and uses that will be the proving ground where the application becomes fully functional and really useful. Just think, there would be no need to wait for the day year when P2 is readily available, you can have it up and running very soon on your favorite close at hand 8-core microcontroller.
@idbruce, this is not to get you to change your horse but this guy says his little interpreter is
" It looks like the GCODE interpreter is going to be about 3K of code on top of about 4.5K of eForth. Not a fancy interpreter by any means but it'll work (I believe)." Now that is some serious thought compression from a FORTH runtime. Anyway just have some fun whatever you end up doing, not that the fun always comes easy.