Shop OBEX P1 Docs P2 Docs Learn Events
P2 GRBL printing text on a Creality Ender3 with a red sharpie.... - Page 3 — Parallax Forums

P2 GRBL printing text on a Creality Ender3 with a red sharpie....



  • RaymanRayman Posts: 13,860

    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...

  • RaymanRayman Posts: 13,860

    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.

  • RaymanRayman Posts: 13,860
    edited 2024-03-26 21:18

    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...

  • RaymanRayman Posts: 13,860

    @DKB said:
    Try a G92A0. G92 usually resets an axis to a specified value.

    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...

  • RaymanRayman Posts: 13,860

    @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...

  • RaymanRayman Posts: 13,860
    edited 2024-03-28 18:54

    @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".

  • RaymanRayman Posts: 13,860

    Buffer size in FDS looks incredibly small:

      BUF_SIZE = 64

    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...

  • RaymanRayman Posts: 13,860

    FDS wasn't ready for a giant buffer... Had to add some # in assembly:

    incmod t2, ##(BUF_SIZE-1) ' update head index

  • i'll put in a timer and see what the max time between checking for "serial data in" is in my code.

  • RaymanRayman Posts: 13,860
    edited 2024-04-05 15:21

    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.

  • RaymanRayman Posts: 13,860

    Might try diamond drag to etch glass next:

  • RaymanRayman Posts: 13,860
    edited 2024-04-06 18:08

    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.

    1512 x 2016 - 722K
  • RaymanRayman Posts: 13,860
    edited 2024-04-06 18:26

    @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...

  • RaymanRayman Posts: 13,860

    @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.str(string("Grbl 1.1h ['$' for help]",10)) '"ctrl x" soft reset
          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
                 c := term.rxcheck()
               until c==10
  • @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...

  • RaymanRayman Posts: 13,860

    Got a new diamond drag tool to try this with soon…

Sign In or Register to comment.