@droftarts Thank you very much for your feedback. I'm looking at quadrature linear encoders that should be easy to connect to the 1HCL quadrature input. However I still have two questions:
Regards,
Marc
Hello,
I'm currently considering adding linear magnetic scales to a large CNC router with stepper motors and currently running with a Duet2Wifi board. There are two reasons for this modification:
So I was considering replacing the current Duet2 board with a Duet3 plus 1HCL expansion boards. However so far I have only seen rotary encoders used with the 1HCL. Is the use of linear encoders also supported by the software?
Regards,
Marc
Thank you for the clarification. I think generally it is hard to define which should be modal and which not for all cases. What about an additional g-code that limits all modal commands on a line to the scope of a macro.
Or even more advanced mechanisms where the user can start and stop a new scope similar to C/C++ (e.g. Gxx.1 starting and Gxx.2 stopping a scope and even a Gyy in front of a modal command to render it global)?
Hello,
is there somewhere an overview which modal commands like e.g. G54, G90, G91... are limited in their effect to the macro scope and which are global?
Currently when testing 2.03RC1 it caught me by surprise that G54, G55.... are not restricted to the macro scope. I thought this was the case with 2.02 but I might be wrong...
Regards,
Marc
No, the Z max value set with M208 is 140. So I basically want to send the head all up.
I run all this in G54 which before running G30 was in a state that 113.65 in G54 would have corresponded to 140 in G53 (machine coordinates).
Yes, I built it myself from GitHub. Saw the tag and was not aware that it is not officially out yet.
Hello,
I just tested 2.03RC1 for my CNC router and run into the following issue using a simple switch for z-probing.
I'm not sure what is the reason for this behavior.
Regards,
Marc
@Guffy : nice work, thanks for sharing. Looks very clean, better than the Mach3 template I worked off from. I will eventually try to change to your PP....
@dc42: ok, thank you!
PS: ...regarding G53 I checked Heidenhain and Sinumerik.
Sinumerik: Seems to use G53 just a another predefined coordinate system from the machine even including tool compensation. By adding D0 tool compensation can be deactivated tough. However for the purpose of tool change Sinumerik provides the G74/G75 commands. But they are used a bit differently as you can predefine machine specific points than then are selected with these commands.
@dc42: Normally M25 calls the pause.g and M24 resume.g if present. In there is my spindle stop / retract and my spindle start / re-approach code. However the pause command called by M915 seems not to execute those procedures (that is why I called them explicitly which as you predicted didn't work either). Is there a reason for this?
@dc42 : Starting a new program is typically no problem as CNC program always explicitly contain G90 or G91 already at the beginning.
My specific problem at hand if I have a stall detected I want to re-home during a program. So I have in rehome.g
M24
G28
M25
where G28 again calls homeall.g which contains a G91 at the beginning and a G90 at the end. Assuming the program was running in G91 before the stall this would generate a problem...
PS: Could the problem be hacked around by call a Macro from the homeall.g?
@dc42 Thanks for the hint. That helps...
PS: ...is my assumption right that the behavior is the same for *.g files in the system directory?
Sorry, I correct my statement. If dealing with non-Cartesian systems like in hang printers or 4- and 5-axis systems relative G53 moves could make sense.
However still wondering how Haidenhein an Siemens deal with the problem...
PS: is a G90 or G91 called from within a macro still active after the macro is finished? If so is there a way how the G90/91 mode active before the start of a macro could be re-established after the macro... this would be another way to deal with the issue....
@Danal sorry for being ignorant, but I don’t get it: A machine can only have one physical position. Assuming that we don’t deal with rotated coordinate systems which coordinate system you are in is only relevant for G90. In G91 mode coordinate systems are completely irrelevant as the move is just added to the current physical position independent of in which coordinate system they are represented i.e. the selected coordinate system only affects the numbers displayed but not the real position.
Please help me if I miss something here....
@mwinterm said in G53 command:
In Wikipedia it states:
G53 Machine coordinate system : Takes absolute coordinates (X,Y,Z,A,B,C) with reference to machine zero rather than program zero. Can be helpful for tool changes. Nonmodal and absolute only. Subsequent blocks are interpreted as "back to G54" even if it is not explicitly programmed.
If tool length compensation would be considered this would not work for tool change (which is my problem).
https://smithy.com/cnc-reference-info/coordinate-system/machine-position-commands/page/0 also states: Regardless of any offsets that may be in effect, putting a G53 in a block of code tells the interpreter to go to the real or absolute axis positions commanded in the block.
Another reference on Youtube.
I think it is very clear that G53 is referring to absolute machine coordinates.
The current behavior of G91 in combination with G53 means G53 is effectively ignored. I also can not imagine how a relative move in machine coordinates should look like. Ignoreing G53 would mean a modal command precedes a specific command like G53 which is also wrong in my understanding.
@Catalin_RO I can not follow your example as a combination of G91 and G53 means thatG53 is ignored, so no need for using it...
On the other hand the current situation can be very dangerous. If someone happens to work with G91 and then issues a command like Tool probing, tool change, lubrication routines.... they will not work correctly and can lead to potential crashes.
The Fanuc behavior described by @timcurtis67 is save but still I believe G53 should temporarily override G91. When working in G91 and I e.g. want to remeasure my tool I would first have to issue a G90 (not a big problem) but after the tool probing I have to remember if I was in G91 and if so re-issue the G91 (very impractical).
I can check next week how Heidenheim and maybe as well Siemens is behaving.
@dc42 I detected another behavior of G53 which I believe is not correct. If G91 is selected G53 also makes relative moves which I believe is not correct. As outlined in earlier posts G53 is typically used to move to fixed machine position e.g. for tool change... This should happen independently of if G90 or G91 is selected.
@dc42 good idea and indeed the M400 updates the tool position. However if I put the M400 in the corresponding tpostX.g files the position is not updated and a corrective z-movement still happens with the next G0/G1 move. First I thought that the tpostX.g files are not executed. But then I modified tpost0.g to
G10 P0
M400
G10 P0
and the the other tpostX.g files accordingly. Now with every TX tool change command I get the tool information reported twice which shows that the scripts are executed. However the M400 is not updating the tool position when called in the tpostX.g. If I call it manually again after the T command everything it does its job again...
@dc42 First of all thank you for pointing me to the right thread.
I'm using a DuetWifi with the latest firmware 2.02 to control a CNC router and experience the same problem in the CNC context.
T0 ; select tool 0
G0 Z50 ; move to position Z50, position shows Z50
G10 P0 Z0 ; set tool lengths of tool 0 to 0
G10 P1 Z10 ; set tool lengths of tool 1 to 10
T1 ; select tool 1, position still shows Z50 instead of Z40
G91 ; go to relative positioning
G0 Z0 ; no movement is expected to occur however Z moves down 10 and now correctly indicates Z50
T0 ; select tool 0 again, position shows Z50 instead of Z60
G0 Z0 ; again no movement expected but Z moves up 10 and again correctly displays Z50
As explained by @dc42 the Z position is not updated after a tool change and with the first G0/G1 move the difference is noticed and compensated by an according move which obviously can make sense in a scenario when a tool change is executed between two tools / heads with very similar length.
However in a CNC setup this behavior is wrong and potentially dangergous as it leads to unexpected Z-movements which are not alwyas small as tool lengths can greatly vary (and believe me it is not fun when my 3.5t Mikron with a maximum table load of 1.1t makes unexpected moves... ;-0000 
However I'm even doubtful that it is a good behavior for a dual head printer as the z-correction done with the first G0/G1 move (typically resulting in a slanted move) can potentially lead to a collision with already printed material when switching from the longer to the shorter tool. I think the Z-move to the correct height should be executed before any other movement. Therefore in my opinion @dc42 's first proposal (Require that all users of multi head FDM machines use tpost#.g files with a G1 R2 Z0 command at the end of each one) would be the way to go.
However I learned that selecting the tool twice is a work-around that is kind of solving the problem for me at the moment. But longer term there should be another solution as it is awkward and kind of hard to explain to CNC guys why the should always do two tool changes...