Topics created by mwinterm

@mwinterm said in CNC router with stepper motors and linear magnetic scales:

Why is a rotary encoder needed as well?

The shaft encoder handles motor commutation (ie turning the motor phases on and off), the linear encoder is used to close the loop. As the motor is being driven more like a servo than a stepper motor, this feedback is needed.

It may be possible to use the linear encoder only in 'Assisted open loop mode'; I'll have to check with @dc42. In this mode the motor is operated as if in open loop mode, but whenever it is detected that the error between desired and actual position is getting too high, the motor current is automatically increased until the error is reduced.

Sorry, this won't work, because assisted open loop mode still uses the shaft encoder to detect slippage.

There is only 1 quadrature input on the 1HCL. Does this mean the rotary encoder needs to be a magnetic encoder to be connect over the SPI encoder input?

Yes. Another advantage of magnetic encoders is that they have a much higher resolution than Quadrature encoders. Connecting encoders is covered here, under : https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Expansion_1HCL#encoders

Ian

You can already declare local scopes using the M120 and M121 commands. The values saved and restored are the same ones as for macros.

Do you think the current workplace number (selected by G54, G55 etc.) should be saved and restored too? On the plus side, you would be able to reserve certain workplace coordinate numbers for use by particular macros, knowing that at the end of the macro you would be back in the original workplace number. On the minus side, you would not be able to have a macro that switches to a different workplace number and leaves the system in that workplace when you exit the macro. I think I'll start a new thread about this.

@mwinterm said in G30 / G31 issue with 2.03RC1:

I switch on the machine Home all Axis G10 L2 P1 -> Origin of workplace 1: X100.00 Y100.00 Z38.50 U0.00 V0.00 (from config-override.g) G10 P1 -> Tool 1 offsets: X0.00 Y 0.00 Z12.15 U0.00 V0.00 active/standby temperature(s): 0.0/0.0 (from config-override.g) G0 X0 Y0 move to the probing point I probe z-level using G30 I issue G0 Z0 to check if the tool moves to the probed level -> everything good (note the new probed level is different from the initial one) I issue again G10 L2 P1 -> Origin of workplace 1: X100.00 Y100.00 Z38.50 U0.00 V0.00. This result does not make sense to me. I would expect the Z-coordinate to be different according to the new probed level.
7 . I move to probe away to maximum Z-level using G53 G0 Z140 -> crash into the mechanical top level endstop After the crash the z-value displayed is Z113.65 which happens to be the maximum value possible with the initial calibration (113.65 = 140 -38.5+12.15)

Please can you try firmware 2.02RC3 and see if this issue is resolved. There have been fixes to handling workplace coordinate offsets between RC2 and RC3.

https://forum.duet3d.com/topic/8181/tool-offset-honored-but-not-displayed-correctly

@dc42 : Thanks a lot for the info!

@mwinterm said in Extension of M408:

Further does does the Firmware update position at all during a move or is the position only updated at the beginning / end of the move? I realized that feed adaptions are only executed for the next G-code line coming up...

The user positions are updated at the start of as move, and the machine positions at the end of a move.

Hello,

i'am also interested in. Do You have maybe any update?

Thanks!

Regards,

Daniel

That is great news!

DC42, 1) Is there documentation detailing the deviations between the NIST Standard & RepRap? 2) Are there any plans to modify the RepRap deviations so that the NIST Standard is followed rigorously?

Link to NIST Standard for reference; https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374

In my opinion this is where a Duet powered CNC differs from other CNC machines in a good way.

Typically the other CNC machines are run from a different computer/device over USB (using some form of Gcode Sender software) - USB (or more specifically an older Serial connection) is slow, have delays and a few other factors making it less ideal to send a lot of small line segments in quick succession (this is why I don't like to 3D print over USB and also advise against it). For these machines to implement such an arc feature where the arc is sent as a single segment, then divided into smaller segments by the machine machine (in all 3 planes), makes a lot of sense (less data to send).

The Duet in comparison have high speed SPI to the microSD card, uses a much more capable processor and thus can read the line segments in quick succession without the delay of Serial over USB.

I have, with my Duet powered CNC cut wavy shapes and they came out smooth (without a noticeable stutter, using the Post side segmentation - having a powerful PC calculate them is more efficient than having to calculate them on an under powered processor as long as you can get all of the information transmitted/read fast enough).

@dc42: ok, thank you!

PS: ...regarding G53 I checked Heidenhain and Sinumerik.

Heidenhain uses G53 in a different context (selecting a WCS from a table of WCS). However the equivalent to our G53 are M91/M92. The allow for relative positioning. Tool length and other compensations are not respected. They are used for positioning the machine on specific positions on their axis as for tool change, etc.

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.

Unless other users express disagreement, I'll add it to the work list for the next release to change G0 not to segment moves solely for mesh bed compensation, when the machine mode is CNC or laser.

@mwinterm would you be able to provide a link for the xtensa-lx106-elf-gcc cross-compiler? This is the only remaining issue I cannot seem to solve and I have tried downloading from several sources but they do not seem to work. It would really appreciate if you could provide some information on this.

The Duet085, Alligator and RADDS configurations don't build. I haven't deleted them yet in case someone else wants to work on them. In particular, there are a few RADDS users interested in getting RRF 2.x running on it.

@chrishamm: First sorry for the late feedback your response somehow escaped me.
I would be happy to have version 2 under something like S2 and agree that the current behavior should be maintained.
But I would also implement Version 1 in parallel as I think it is completely consistent with the current behavior. It is just extending the current behavior to work as well with initial tool-offsets different from 0.
Finally if you like I can make a pull-request from my repository. However as it is so little code I'm not sure if it is not easier for you to directly include the few lines needed. Whatever you prefer just let me know....

Thanks for confirming this.