Very frustrated. TinyG 440.20 on a Big OX,

Very frustrated. TinyG 440.20 on a Big OX, Chilipeppr running gcode generated by JSCUT via dedicated laptop running JSON V1.88. There is a definite buffer issue with my job. The only way that the job starts cutting at the proper point is if I have no pre-load and no multi-line upload set. It will only start at the correct point if it is sent commands slowly. If I try to buffer any lines the GCODE widget shows that there are commands executed when they have NOT been executed. This always occurs during the time that the first “Rapid to initial position
G1 X-0.8511 Y-10.1465 F100” line is being performed by the OX. This initial move is quite a distance as the workspace origin is at the center of the workpiece and the starting point for the first cut is over 11 inches away, and it takes a bit of time to do the move. During the time that the spindle is moving to the starting position, any buffered gcode is marked as executed even though it has not been. The result is that a large number of gcode commands are effectively skipped and the cutting starts at the coordinates of the last gcode line after the one that the widget shows as being executed. The GCODE widget, 3D viewpoint and physical spindle stay in sync, but they go to the wrong point. Every gcode line in between is skipped, including, in this case, the commands to start and plunge the spindle, which immediately follow the first move to initial position. If I do turn on any level of buffering or preloading, the final coordinates of the spindle initial move are those of the last command that the system thought was executed. I don’t know who is screwing up here, ChiliPeppr, JSON or TinyG. It is my understanding that the TInyG acknowledges execution of a command, so that would indicate that it is saying it executed a command when it didn’t, but I don’t know enough to be sure of that, or what to do about it if true. The first picture shows ChiliPeppr as the OX is moving from center 0 to the initial cut point with no pre-upload, but multi-line set to 50 lines. Chili reports that 47 lines have been sent and executed while in actuality the OX is still working on Line 18. The second shows Chili just as the next 50 lines have been sent and the system thinks that the spindle is cutting. Because the plunge was skipped, the spindle is still at Z0 but the command thinks it is at Z-0.060 and the cut is beginning in the wrong place. Picture 3 is the OX starting its cut at the correct place when there is no buffering taking place. Picture 4 is an oddity that I saw in the Chili Gcode widget in an attempt to run the code with a pre-load of 100 lines and multiline of 50. I don’t know if this a a cause or effect, or something completely different. Can anyone who is still reading this thesis help me figure out what is wrong? Thanks in advance.

A full screenshot would help because this partial one you posted seems to look like no workspace I know of where the serial commands are on the right side and the gcode widget is floating. It sounds like you’re either using some weird workspace, or your own, or maybe you didn’t choose the tinyg buffer in the spjs widget. Can you post a good full screenshot?

Hmm. Looked further and it does seem like you’re in tinyg workspace but can’t see if you picked the tinyg buffer in the spjs widget.

Hi John, Google is sticking my individual pictures together that makes it look like my snippit from the gcode file is in the same shot as the ChiliPeppr screenshot. There are five individual pictures. On the tinyG buffer in the spjs, I didn’t even know about that until I read more about the JSON server program, so I went to chilipeppr/serialport on my laptop and it did indeed show that the tinyg buffer was being used. It gave a list of possible buffers too, so does that indicate that I was in the right place?

I will take full-screen captures tomorrow. This is VERY repeatable. The only think that changes is that the number of commands I try to buffer in effect moves where the spindle thinks that it is starting to cut.

Well, so much for repeatable. I stepped away from it for a day. Yesterday I restarted everything and went back to the point where it was messing up and it was all working fine. Instead of the GCODE widget blasting past a bunch of commands and marking them as executed while the spindle was still moving to the initial start position, it worked just as it was supposed to and the widget sat at the line being executed until the spindle reached the correct starting point. It then proceeded as intended. So, somehow, somewhere along the way something was amiss in the communication between Chili and the TinyG. A fresh restart of all elements involved seems to have cleared it up. I think my SOP from here on is to always restart everything from the power-off stage, run Chili in a incognito window and whenever a session is complete, or something doesn’t work as expected, shut everything down and start from scratch. Even then, once I ran into a situation where after loading my gcode and moving the spindle to the G56 zero, I tried to jog the Z axis and it wasn’t working right. My gcode is in inches and the AXES widget showed inches as the units, but the jog was moving in millimeters. Sending G20’s and G21’s didn’t change the units in the widget or the jog units. Red Flag. I shut the whole thing down and restarted from scratch and it then worked as expected; inches were inches. When it works, it works great, but I am learning not to assume all is well, and if ANYTHING looks at all odd, shut it all down and restart from scratch. Thanks for watching.

Well, my gut still tells me you didn’t have the buffer set to “tinyg” in the SPJS widget and thus why your lines executed without any holdback. As for the units on jogging, keep in mind the units in the Axes widget is different from units in the 3D viewer. That’s because your Gcode file can have one set of units while your jogging is a different set. I just make sure I use mm all the time so I don’t end up with that confusion.

Well, John, you are probably right, but I really don’t know as I wasn’t even aware that the buffer type was selectable in the JSON widget until it was mentioned and I did a little more research on it. I have always just let the whole thing run in whatever the default is since I am way to dumb to know how any of this stuff works under the hood. I could very well have inadvertently changed the setting without realizing it. I’ll learn the little details as I gain experience, but for now, it is start from scratch every time and leave the defaults alone! Thanks.