Direction Control in RRF

NineMile

I've used my VFD for a while with only forward-run in RRF and it's worked great. Testing some things recently and now I realise direction control in RRF appears to be incompatible with my particular VFD (Inovance MD200-NC). As far as I can tell, a 3 pin configuration in RRF for the spindle will treat the second pin as ENABLE and the third pin as DIRECTION - where direction is pulled high or low depending on forward or reverse being selected.

Unfortunately, my VFD doesn't appear to be configurable to allow this style of control - it expects either a FORWARD RUN or a REVERSE RUN signal, if it receives both it stops.

I haven't seen a way to configure RRF output as FORWARD or REVERSE output, and likewise I also haven't found a setup on my VFD that allows it to take a 'direction' input in the way that RRF intends.

Am I missing something? Or should this be a feature request on the RRF repo?

hurzhurz

~~@NineMile Actually, it works in the way you need it, with separate run-pins for forward and reverse:~~

M950 R0 C"pwm_pin+forward_pin+reverse_pin" Qfff Laa:bb

(see example in the GCode dictionary under "M950 / Configuration examples and notes / Spindles")

gloomyandy

@hurzhurz Nope looking at the code: https://github.com/Duet3D/RepRapFirmware/blob/3.5-dev/src/Tools/Spindle.cpp#L127 I'd say that @NineMile is correct, the first pin is used as enable and the second pin is used as the direction.

hurzhurz

@gloomyandy Oh ok, you are right. And now I see it is actually discribed that way in the documentation, dispite the pin-name examples suggest it is like the way I thought it is.
Well, and my own VFD also has forward-run and reverse-run inputs... maybe it doesn't care if both are active and gives priority to the reverse input.

Maybe the implementation in RRF is not that optimal?

@NineMile maybe you can build a little circuit with a logic gate to convert the signal

droftarts

@hurzhurz If you read the description right under the part you quoted, you'll see that's not the case. I've changed the pin names to:

M950 R0 C"pwm_pin + on/off_pin + forward/reverse_pin" Qfff Laa:bb

This was also discussed here, and I tested it: https://forum.duet3d.com/post/329316

@NineMile As to why it's like this, I expect when it was implemented this was the way whoever requested it wanted it. Raise an issue for the alternative, though I can see a problem trying to switch two pins at the same time, or having to have a pause between switching one off and the other on.

Ian

NineMile

@droftarts Thanks, I'll put in a feature request.

For what it's worth I think I'll modify a local build and see if the pin switching thing will be an issue in my particular use-case, but I suspect the timing is not an issue - if both forward and reverse are active then the spindle won't turn but it does not put the VFD into a fault state, and as soon as one of the directions are deactivated then the spindle will start spinning in the direction that is still active (and will decelerate to a stop before changing direction).

ETA: Confirmed, on my VFD at least there is no timing concern if the pins are not switched at the same time / there is no set delay - the spindle will just stop if both are active at once.

timschneider

@NineMile
in the meantime you can try to use the 3-wire interface of most VFD's

https://forum.duet3d.com/post/328945

NineMile

@timschneider Thanks for this - I haven't quite decoded how the 3-wire setup works on my particular VFD yet but when I do, I might give it a shot.