3.4rc1 early feedback

Sindarius

@markz You'd have to thank Christian for that

Sindarius

@markz On the step buttons you should be able to right click and type in the step amount you want the buttons to execute.

markz

@sindarius Yes, I've used that, thanks. Also, maybe to christian ->

the message boxes have been moved to midscreen - bless you : )

markz

Updating a 6HC -> it appears that the RC1 misnamed the sDiap file for the 6HC to 6XD. I renamed it and used it just fine. Thank you for documenting the static IP change - a few seconds of tearing hair until I remembered.

dc42

@markz it should have provided IAP files for both the 6HC and the 6XD. The two binaries are similar enough that each one is likely to work on the other board except for the LED indications.

markz

@dc42 Oh, thanks. I'm glad it worked for me as is (oops).

On another note... the mid-center message is important enough that I updated my mill to RC1 and the first job well,... I usually design in mm and manufacture in inches and the job interpreted the numbers as mm even with a G20 in-file (and I compared the gcode to a prior job and the headers were the same). When I had Fusion generate the same data as mm the job ran fine. Luckily I have a physical E-stop.

dc42

@markz said in 3.4rc1 early feedback:

@dc42 Oh, thanks. I'm glad it worked for me as is (oops).

On another note... the mid-center message is important enough that I updated my mill to RC1 and the first job well,... I usually design in mm and manufacture in inches and the job interpreted the numbers as mm even with a G20 in-file (and I compared the gcode to a prior job and the headers were the same). When I had Fusion generate the same data as mm the job ran fine. Luckily I have a physical E-stop.

Please explain what you mean by "the mid center message".

Note, object model values are always reported in mm; and each GCode source has its own inches/mm setting.

markz

@dc42 Thanks for the reply.

The 'mid-center message' is moving the warnings to horizontal center instead of covering the macros. Seems dumb but really important on a tablet.

The object model isn't the issue. In my job, starting at 0,0,Z the bit was supposed to go down to just above material then rapid to one corner and then drop and start milling. Instead, it jammed the bit down to the bed and dragged it an inch or so. It was interpreting the data as mm as far as I could tell. Just regenerating the data in mm milled fine (and the script in the gcode file contains a unit-setter G20/21). Note I've been successfully milling in inches with 4.3 for months though I always keep the GUI in mm.

And to be clear I haven't retested and I think it was a units problem.

markz

@dc42 I took a much longer look at the g-code and I don't see how it could be a units problem. The MinY is -1.8 which wouldn't have caused that gash in mm, so I guess I have no idea what happened.

dc42

@markz did the GCode invoke any system macros, such as homing macros, tool change macros, or the pause macro? When macros are invoked, the existing inches/mm setting will be used, unless you start the macro file with G20 or G21. Therefore, if you use G20 in your GCode jobs, it's best to use G21 at the start of every macro file (assuming you use mm in your macros) to ensure that values in the macro are interpreted in mm. The previous inches/mm setting will be restored automatically when the macro completes.

You can read the current inches/mm setting for each input from the object model:

markz

@dc42 Thanks, that's good to know. I'll dumb-proof my macros.

Yesterday I ran a bunch of jobs using various unit settings and they all ran flawlessly, so... I'm going to put it down to user error for now.