From the original Synthetos forum (2011–2025)
If I use my windows to cut anything on my CNC (tinyg) with jscut and chillipeppr it cuts perfect and finished product measures perfect.
However it I use universal G-code sender on a raspberry PI created on JScut
it cuts about 10 - 15% bigger in size which the SVG file was created
or using windows chillpeppr.
I have selected the tinyg in the pull down, but don't see other settings.
Any ideas?
I guess my one question... Is when I first setup chillypeppr I had to adjust the settings $1tr, $2tr and $3tr settings on the tinyg. So I assume
you don't need to adjust these for UGS as well. Or do you need to calibrate these settings for each type of Gcode sender ie chillipeppr and UGS?
Thanks
So I assume
you don’t need to adjust these for UGS as well. Or do you need to calibrate these settings for each type of Gcode sender ie chillipeppr and UGS?
The $_tr settings are machine settings, dependent on the mechanical characteristics such as gear ratios or pulley/belt designs. What sort of machine do you have (belt, screw, etc)?
The coordinates of actual movement are coded into the Gcode statements.
UGS, at least the version I am familiar with, is a simple line by line file sending tool. It manages serial delivery of the Gcode statements between the sender machine and tinyG.
Chilipeppr is a CAM software tool and could be programmed to modify Gcode dimensions on-the-fly, but I have not seen that feature implemented. An example of Chilipeppr on-the-fly modification would be the "Feedrate Modifier in the Gcode widget, which modifies the streaming Gcode "F" commands dynamically.
You are loading the same (identical) Gcode file into UGS and Chilipeppr, correct?
UGS running on Windows and on RaspberryPi should perform the same as well, have you tried that?
Same code file on chillipeppr and UGS. It gives same results on windows and on the windows and pi.
I connected the pi. Then measured the xy position. Moved it 100mm and it
was spot on. So it not a cablibration
I don't know jscut at all, but believe it supports cutter diameter compensation. Is that turned on perhaps?
Looking back thru this thread, I see I don't know a lot about your setup, e.g. the type of machine (belt, screw, other). This could be due to loose pulleys or mechanical couplings, that measure OK in linear direction, only x or only y, but simultaneous X and y cause things to slip.
Also, I am assuming this is all focussed on a machine connected to a tinyG running FW 440.20, not G2core running on a DUE or something similar.
Posting your tinyG settings (a $$ dump) to a cloud drive and providing a URL link would reveal a lot.
Well figured out that it was not cutting too big but rather the tinyg
was remembering the last home of G54.
So with the Raspberry PI 3 Universal Gcode sender the reset or set to zero on the X/Y doesn't work.
So if I used plink to check $g54 it would be off. Thus the cutting was off
center and often off the cut object.
If I use the Universal Gcode sender to Jog and move to where I want zero to be. This disconnect UGS and on the PI use plink and set
G10 L2 P1 X0 Y0 Z0
Check $54 which should be 0, 0 , 0.
Now using UGS I can easily send the file and it matches perfectly.
Thanks
OK, understand what you are doing.
Good luck.
I assume you are aware that moving , by jogging or just grabbing the spindle and moving by hand, then resetting tinyG should reset the current position to 0,0,0.
This topic is from the original forum (May 2017). Your reply starts a new discussion linked to it.
Back to TinyG Support or latest activity.