I have a lulzbot Taz 6. I’m a graduate student working on a project where I want to track what happens during a 3D print, and compare that to gcode instructions. That is, I want to compare what actually happens during a print to what was intended by the gcode.
Specifically, I put rotary encoders on each of the stepper motors for my printer, allowing me to record the print head’s trajectory, and I want to compare that to the instructions that were sent to the 3D printer. This means I have to write a program to parse gcode and figure out where the print head should be at any given time.
I notice that even when I run the printer very slowly, without any acceleration or jerk control, I’m not able to get the parsed gcode trajectory to perfectly line up with the encoder recordings. My assumption is that when there are a couple of lines of gcode like this:
G1 X30.000 Y30.000 F500
G1 X150.000 Y30.000 F500
the print head will go from (30, 30) to (150, 30) at a speed of 500 mm/minute. This would take 14.4 seconds, but in reality, it seems to take slightly longer. Does anyone know why it takes longer and how I can accommodate for that with my simulator? The printer isn’t applying acceleration or jerk control, so I thought the timing should exactly match up (even though the print head might miss its mark sometimes).
A 3D print head is a physical object with mass and it is impossible to instantaneously achieve 500mm/minute. The printer IS applying (i.e. using) Acceleration and Jerk to assure that the print head does NOT miss its mark).
If you had multiple G-code commands (0,30) (30,30) (150,30) (180,30) then it might be possible for the x=30 to x=150 move to be at a constant 500mm/minute but any change in direction between any two commands must include some adjustment for the inertia of the print head.
If you want your Python simulator to match the print head movement exactly then you are essentially translating the Marlin firmware (written in C) into Python.
You might find some interesting reading at https://www.klipper3d.org/ as most of the code is written in Python.
I realize that the physical object can’t instantaneously change velocity. I removed the acceleration and jerk control from the printer though, so it seems to me that it would still send instructions to the steppers as if it could instantaneously change its velocity.
So how does the printer know when to issue each command? It isn’t issuing any acceleration control, and the steppers don’t have any sense of where they are at any given time.
How did you remove the acceleration and jerk control? Custom firmware? While you can program the firmware for “no inertia”, you can’t take the inertia out of the physical system.
Furthermore, stepper motors don’t instantaneously step. Have a look at the sample code on this page. The basic examples all have a delay in them. Even more details on stepper motors can be found here.
As long as you are measuring and simulating a physical system, you will have to simulate the physics to get anywhere close to accurate comparisons. For example, here is a project to improve the estimate of print time. It includes a firmware simulator written in Python.