VFD Spindle...

dc42

I have installed a PWM to Analog board on an Ooznest/Duet Router to provide 0-10V to control a VFD Spindle. This is all working very nicely on E0 apart from a Pause / Resume issue that I would like to implement. I would like to stop the spindle (M5) in the pause macro (that's fine) and restart again (M3) in the resume macro. The problem is that M3 without Saddress gives 0v output, so the previous spindle speed is lost and S0 is assumed for M3.
Of course, I don't know the spindle speed in the resume macro, but wonder if there is a way. I notice M120 (push) and M121(pop) but not sure if this is the correct approach?

That's not supported at present, but I can see that it would be useful. Similarly, the original laser power should be restored when pausing a laser cutter or engraver. I'll add it to the work list for RRF 3.

geoffh

Thanks. I have another issue with M5 (spindle stop), that it does not finish buffered moves prior to executing. In my case, I had a program that had about 60mm of cutting to finish, when the spindle was stopped I also noticed that moves were executed prior to M3... but I solved this with a G4 pause, so I'm planning to do the same prior to the M5, or should I use M555 P?

nhof

You may be able to fix the problem by adding a M400 command before the M5 command.

M400 should ensure all buffered moves are completed before executing M5.

Can use it at the beginning of pause macros as well.

dc42

@geoffh said in VFD Spindle...:

Thanks. I have another issue with M5 (spindle stop), that it does not finish buffered moves prior to executing. In my case, I had a program that had about 60mm of cutting to finish, when the spindle was stopped I also noticed that moves were executed prior to M3... but I solved this with a G4 pause, so I'm planning to do the same prior to the M5, or should I use M555 P?

That's not right. M3 and M5 commands read from SD card files are synchronised to the movement queue, so you should not need to use G4 or M400. Are you certain there is a problem? Can you reproduce it? Note, M3 and M5 commands sent from the GCode Console of DWC will be acted on instantly, because DWC is treated as a live input channel.

Catalin_RO

@dc42 I also confirm the bug! Since finding the issue, about a year ago, I have configured my CamBam post processor to issue G4 P0 M5 as the command for turning the spindle off.

As a side note, if I there is any G0/1/2/3 command that would end outside the machine limits, the spindle is turned off (with 800W and more the RPM dropping is clearly heard) before the file execution is stopped and the last queued movements are done with decreasing spindle rotation. This is still true even for 2.03!

dc42

@catalin_ro said in VFD Spindle...:

@dc42 I also confirm the bug! Since finding the issue, about a year ago, I have configured my CamBam post processor to issue G4 P0 M5 as the command for turning the spindle off.

As a side note, if I there is any G0/1/2/3 command that would end outside the machine limits, the spindle is turned off (with 800W and more the RPM dropping is clearly heard) before the file execution is stopped and the last queued movements are done with decreasing spindle rotation. This is still true even for 2.03!

Please provide a GCode file that reproduces this issue, when run from SD card using firmware 2.03.

I can understand that when RRF detects an invalid move in CNC mode, it may turn the spindle off immediately instead of waiting for previous moves to complete.

geoffh

Thanks for your replies. I have tried to reproduce the problem and cannot!
At the moment I can only confirm the problem when going out of limits, of course for a laser not a problem, but for a mill it will break the cutter or machine or both.
The situation I had yesterday was not out of limit, it was a very simple program, cutting a square in order to calibrate the machine, but unfortunately all I can offer you is an image of the partial cut which I'm sure you are not interested in.
Confused!!
Anyway I'll keep trying to reproduce the problem but with cutter above the workpiece.

geoffh

I have tested again and cannot repeat the M5 problem, my conclusion NOW is that the system thought that the machine was out of limit?
I was machining a square with radiused corners, it had made one pass, descended and started cutting along the final move G1Y130. of the second pass when the spindle stopped. I can only imagine that the G00Z10. was out of limits but I don't understand why since it had been there already. In the horrible mess that followed, I had to make an emergency stop, so was unable to see any error message, and maybe came to the wrong conclusion about the move buffering with M5.
T1
G17
G21G90
G55
G0X0.000Y0.000Z10.000
M3S18000
G4S2
G0X76.825Y130.000Z3.000
G1Z-2.500F200.0
G1Y100.000F1000.0
G3X100.000Y76.825I23.175J0.000
G1X160.000
G3X183.175Y100.000I0.000J23.175
G1Y160.000
G3X160.000Y183.175I-23.175J0.000
G1X100.000
G3X76.825Y160.000I0.000J-23.175
G1Y130.000
G1Z-5.000F200.0
G1Y100.000F1000.0
G3X100.000Y76.825I23.175J0.000
G1X160.000
G3X183.175Y100.000I0.000J23.175
G1Y160.000
G3X160.000Y183.175I-23.175J0.000
G1X100.000
G3X76.825Y160.000I0.000J-23.175
G1Y130.000
G0Z3.000
M5
G0Z10.000
G0X0.000Y0.000
M117 End of Program

I am now trying to simulate an out of limits error!

geoffh

Just noticed that G17 isn't a valid G-code for RRF, I'll get rid of that, but I don't think that has been an issue?

geoffh

Another bad conclusion from me, G17 not documented but is accepted as valid by RRF - GCode Console of DWC

dc42

I have added G17 to the GCodes documentation.

geoffh

@dc42 I have tried to reproduce the problem that I had last week without success. You have acknowledged that RRF will stop the spindle before moves have been completed for "Out of Limit" error. Unfortunately I cannot say what error occurred that caused the spindle to be stopped; and wonder if it would be possible to prevent the spindle from being stopped whilst axes are still being moved for all errors? This behaviour could be restricted to CNC mode. For my machine, the Spindle stops very quickly and so it can be a disaster when the axes continue movement with the cutter inside the material.

dc42

I had added this to the work list for RepRapFirmware 3.