problem in handling of inches vs mm

[imechura]

I have a gcode file that was generated by flat cam. The gcode is inches and it begins with G20. My Arduino nano with grblv1.1 is set to $13=1. on the GRBL Tab this panel that says "Program limits" displays the X value as 73 inches. If I move to the probing panel and select height map and "set from program limits" it says that it is 73mm.

If I run the outline program ioSender, the machine crashes because its trying to move to x=73(inches) when it should be moving 2.87 inches.

Please advise.

[terjeio]

Try the latest edge version. ioSender, like GRBL, works in metric mode internally - and I have not spent much time on coding (and testing) for the archaic imperial measurement system so there may still be bugs lurking. Note that probing only uses metric and all gcode conversions ends up in metric format.

[imechura]

I personally feel that it would be wonderful if everyone on earth could adopt the metric system immediatley, however, unfortunatley, I dont have control over everyone and everything and there are times when it becomes neccessary to interface with and deal with files that where created using inches instead of millimeters.

Im not in the position to tell a customer to go away and come back when they have converted their entire workflow to metric as they will just go find someone else to do the work.

Is this not the latest edge version already ioSender Edge 2.0.42p6?

[terjeio]

I personally feel that it would be wonderful if everyone on earth could adopt the metric system immediatley,

The largest of the few small countries that has not yet completely adopted metric is USA, which by law switched to metric nearly fifty years ago...

Files in the imperial measurement system are not a problem, the complication is when the controller runs in inches mode. That gives me four different scenarioes to work with and I do not have the time nor any real incentive to (re)test every bit of code for that.

Im not in the position to tell a customer to go away and come back when they have converted their entire workflow to metric as they will just go find someone else to do the work.

Luckily I am as I do not have (paying) customers, I have users - so no loss of income if I lose some.

Is this not the latest edge version already ioSender Edge 2.0.42p6?

I have just deleted the p6 (prerelease 6) as the final 2.0.42 has been released - with some further changes for imperial.

[imechura]

Personally, I would would rather pay you for your software and for support equal to what I would get from HAAS, DOOSAN etc rather than to have it for free without the support.

Something that is free that doesnt do what I need it to is not very useful to me. That is just my personal opnion I am sure that many others would disagree.

I took the customers drawing and converted it to metric, regenerated the CAM and gcode in metric, I changed the setting $13=0 and Im still having the same problem.

I am not sure what I did wrong because I am in a rush. I will try the new release and if its still doing the same thing, then I will dig into my files to try to figure it out.

I apprecieate your help, thank you.

[imechura]

terjeio,

I got to thinking about what you said and it dawned on me that I had an $N0=G20 setting in my firmware from a very long time ago. I removed it and the problems disappeared.

That might be worth mentioning on the wiki if its not already there as it could save for a few nerw issues popping up uneeded.

Now having used ioSender without the user errors I caused before I must say that your software appears to be in a different class than all of the other senders I have used (and I have used more than a few). You are apparently a very skilled engineer. Thanks for making this for everyone to use.

Can I please take a moment to ask you an unrelated question? Are there any GRBL or GRBLHal implementations that you are aware of that support analog or SPI interfaces to the motion controller instead of STEP/DIR?

The reason I'm asking is because I have a fairly tall stack of complete 4-Axis Trinamic motion control sytems with Trinamic 5 Amp stepper drives sitting here in my shop gathering dust that I would really like to use for CNC systems. The individual drives support step/dir but the overall system only supports SPI. The individual drives have a 68pin dip connector so using them standalone is not straightforward. Ive way got more of them than I could ever use on my own so if you want one of them then let me know.

[imechura]

Ignore my question. I just looked at the GRBLHal code and it appears to support SPI for some platforms.

But in any case, if you could use a few of these Trinamic setups I have a few to spare. They are older models TMCM-301 controllers with TMCM-035 v2.1 drivers.

[terjeio]

Are there any GRBL or GRBLHal implementations that you are aware of that support analog or SPI interfaces to the motion controller instead of STEP/DIR?

Not any that sends high level motion commands to the controller (moveto etc,), this would require a rewrite of the core. Analog control is possible - via DACs, I added driver support for my STM32 Morpho breakout a while back - as an experiment. This could be extended to support galvanometers?

But in any case, if you could use a few of these Trinamic setups I have a few to spare.

Thanks for the offer - but I have no use for them, I have far more controllers than machines to control...