Was just looking at GRBL source code... Looks like plain C to me.
Seems might be able to compile with FlexC or Catalina...
The tricky part is the timing, but maybe can use what is here for that. Not sure how close this code follows the original though...
On the other hand, seems like I have all I need with this code...
I'm kind of surprised an Arduino can pull off juggling driving steppers with serial i/o and all. Probably pushes some limits there...
@Rayman I found a problem with the code I added for jog, it was messing up the position counters modal was set to absolute and the jog moves are incremental... so I updated the spin program in the top post...
BTW: Is there a serial receive buffer that I have to worry about on P2? It seems that if don't add a delay after sending commands, something goes wrong...
Found a bug in my code that was sending junk... Still wondering how the receive buffer works...
@Rayman
fullduplexserial has buffering built in... my program reads that hopefully before it overflows, it may be configurable.
My program parses the moves and has a circular move buffer of 99 moves... it feeds them out to the interpolator as the prior move is executed... the size of the move buffer is the variable "buffered".
I think the only way this can possibly work is if UGS is calculating the time it should take a move to complete and then wait that time after each command...
Going to make buffer bigger because my code not that fancy...
I'm interested to see if Carbide Create can work with this GRBL. Heard it can, that would be very nice. Also see that Carbide3D has locked down new versions so you can't export gcode unless you pay for the Pro version.
@mwroberts This has to be a bug in UGS right? I'm not seeing how the leading comments and blank lines could mess GRBL up. Are the comments even transmitted serially?
Maybe they are and aren't being handled correctly? Bizarre... Anyway, glad to finally have this working!
Attached the gcode from last test. The first one is the output straight from UGS. It doesn't work. The "alt1" version has the leading comment lines removed and it works...
@Rayman I spent the morning looking at this... I tried your test8.gcode.txt with an actual arduino GRBL, it doesn't lock up.
With the UGS tab set "Follow the running code", the highlighted program line seems to lag the actual g-code line the GRBL is executing.
I think the comment lines are sent over...
Seems like UGS thinks the P2GRBL buffer is full...
@mwroberts Thanks for looking at this. Would be nice if could make work without deleting the comments, but I'm happy it works after deleting the comments.
Tried adding this to skip comments, but seems code never actually executes for some reason:
PUB Report()| strPTR ', index, tPTR1,headPTR,index2
term.start(63,62,%0000,baud)
term.str(string("Grbl 1.1h ['$' for help]",10)) '"ctrl x" soft reset
repeat
c := term.rxcheck()
if c <> 255
if ((c >= "A") && (c <= "Z")) 'make all lower case as they are read in
c += 32
case c
'13 : 'term.str(string("cr",13,10))
";": 'RJA ignoring comment lines
repeat
c := term.rxcheck()
until c==10
pinh(52)
@Rayman I fixed how it handles comments in UGS and posted the new code to the top page. I also added a BaseStepPin constant for easier setup of the step/dir pins...
Comments
Ok, think have it...
Ascale := 40_000*20/360
gives me one rotation at a decent speed with "G1G91A360.0F3600"
Figured out that G91 means to do a relative motion. Good to know...
Is there a way to set a new position as zero?
Rebooting the P2 to do this now, but maybe there's a command to do the same thing?
Seeing some kind of rollover issue with A... After many rotations, it starts turning the other direction...
Try a G92A0. G92 usually resets an axis to a specified value.
Was just looking at GRBL source code... Looks like plain C to me.
Seems might be able to compile with FlexC or Catalina...
The tricky part is the timing, but maybe can use what is here for that. Not sure how close this code follows the original though...
On the other hand, seems like I have all I need with this code...
I'm kind of surprised an Arduino can pull off juggling driving steppers with serial i/o and all. Probably pushes some limits there...
That works, thanks!
@Rayman I found a problem with the code I added for jog, it was messing up the position counters modal was set to absolute and the jog moves are incremental... so I updated the spin program in the top post...
@mwroberts Updated, but not 100% sure it's right...
If given this: G01G90X0.0Y0.0F400.0
Should go to absolute X=0 & Y=0 , right?
Seems to be doing random stuff...
@Rayman
Yes, I fixed it better this time I hope... new Rev d in top post now...
@mwroberts Thanks, seems to work...
BTW: Is there a serial receive buffer that I have to worry about on P2? It seems that if don't add a delay after sending commands, something goes wrong...
Found a bug in my code that was sending junk... Still wondering how the receive buffer works...
@Rayman
fullduplexserial has buffering built in... my program reads that hopefully before it overflows, it may be configurable.
My program parses the moves and has a circular move buffer of 99 moves... it feeds them out to the interpolator as the prior move is executed... the size of the move buffer is the variable "buffered".
Buffer size in FDS looks incredibly small:
I think the only way this can possibly work is if UGS is calculating the time it should take a move to complete and then wait that time after each command...
Going to make buffer bigger because my code not that fancy...
FDS wasn't ready for a giant buffer... Had to add some # in assembly:
incmod t2, ##(BUF_SIZE-1) ' update head indexi'll put in a timer and see what the max time between checking for "serial data in" is in my code.
I'm interested to see if Carbide Create can work with this GRBL. Heard it can, that would be very nice. Also see that Carbide3D has locked down new versions so you can't export gcode unless you pay for the Pro version.
Might try diamond drag to etch glass next:
https://www.sparkfun.com/products/19762
Was really bothering me that UGS was freezing with my little text test.
Tried a bunch of stuff to try to fix it, but nothing was working...
Then, just deleted all the lines at the top of the file that aren't G0 or G1, i.e., all the setup lines and it works.
@mwroberts This has to be a bug in UGS right? I'm not seeing how the leading comments and blank lines could mess GRBL up. Are the comments even transmitted serially?
Maybe they are and aren't being handled correctly? Bizarre... Anyway, glad to finally have this working!
Attached the gcode from last test. The first one is the output straight from UGS. It doesn't work. The "alt1" version has the leading comment lines removed and it works...
@Rayman I spent the morning looking at this... I tried your test8.gcode.txt with an actual arduino GRBL, it doesn't lock up.
With the UGS tab set "Follow the running code", the highlighted program line seems to lag the actual g-code line the GRBL is executing.
I think the comment lines are sent over...
Seems like UGS thinks the P2GRBL buffer is full...
@mwroberts Thanks for looking at this. Would be nice if could make work without deleting the comments, but I'm happy it works after deleting the comments.
Tried adding this to skip comments, but seems code never actually executes for some reason:
PUB Report()| strPTR ', index, tPTR1,headPTR,index2 term.start(63,62,%0000,baud) term.str(string("Grbl 1.1h ['$' for help]",10)) '"ctrl x" soft reset repeat c := term.rxcheck() if c <> 255 if ((c >= "A") && (c <= "Z")) 'make all lower case as they are read in c += 32 case c '13 : 'term.str(string("cr",13,10)) ";": 'RJA ignoring comment lines repeat c := term.rxcheck() until c==10 pinh(52)@Rayman I fixed how it handles comments in UGS and posted the new code to the top page. I also added a BaseStepPin constant for easier setup of the step/dir pins...
Thanks!
Got a new diamond drag tool to try this with soon…