I have looked into this and I think we are getting some scientific notation from the OS! Why is it doing it .... well frankly that is the real issue. Thank you for bringing this up! We are looking for a solution.
Now that Brian brought up scientific notation, I think he is onto something. I think the way xstart and ystart are used to form the string is what is causing the scientific notation to appear.
Consider your script line below. And this could very well happen if xstart and ystart were calculated and are in scientific notation!
mc.mcCntlGcodeExecuteWait(inst,(string.format('G' .. posmode)).." G54 G0 X"..xstart.." Y"..ystart)
Also, if tostring was used to convert the x and y start positions to a string, the positions may be small enough to produce the scientific notation. So how can we prove the scientific notation thing? Try this code:
local gcodeLine = string.format('G' .. posmode) .. " G54 G0 X"..xstart.." Y"..ystart
mc.mcCntlSetLastError(inst, gcodeLine)
mc.mcCntlGcodeExecuteWait(inst, gcodeLine)
Now, what if the above code proves that out to be true? How do you eliminate the issue? Consider this code, assuming xstart and ystart are real number variables and not a string representation of numbers. This also assumes that posmode is a number.
local gcodeLine = string.format('G%d G54 G0 X%.4f Y%.4f', posmode, xstart, ystart)
mc.mcCntlSetLastError(inst, gcodeLine)
mc.mcCntlGcodeExecuteWait(inst, gcodeLine)
The above code is the proper way to use string.format() %d is an integer. %f is a floating point number. %.4f means 4 digits of precision. See if that gets better results.
Steve