wj200 modbus driver in master - tried it out

Hi, all.

Just wanted to document somewhere that I tried out the wj200 driver that made it into master recently.

I have it set up on my milling machine, which is a lagunmatic 250, three axis with DC servos and aerotech servo drives controlled via a Mesa 5i25/7i77 combo. I'm using a SuperLogics 8520 RS-232/RS-485 converter on the first serial connector on my Gigabyte E350 motherboard.

It works well so far. Frequency setting, stop and start, tripping the drive if not enabled, reversing, etc via pins in HAL.

Notes about getting it set up, documented here for anyone else what wants to try it:

There are a couple of gotchas. The port, baud rate, and comm settings are currently hardcoded. To use a port other than ttyS0 you have to edit it and recompile. Likewise for any speed other than 9600bps. 9600 seems usable though, and going to 115200 won't lower latency enough to do positioning or tapping anyway. You can skip using termination resistors on both ends of the connection unless you have a ton of noise for some reason. Recommendations by various manufacturers state that if your RS485 loop is under 2000 ft and 9600 bps or under, no termination resistors are needed.

It's a two wire interface between the converter and the wj200 front panel, so it's half duplex (2 wire) RS485. You use the sp and sn (+ and -) terminals for this. There's an RJ45 on the vfd, but it's for a remote control panel only, not ethernet.

You connect the terminals like to like, so the sp terminal on the wj200 connects to + on your serial converter, and the sn terminal connects to the - on the converter. Most converters like the one I have require external power. I used the same 24v supply that gives field power to my 7i77 board.

The serial cable I use for the converter is a 9 pin M-F, straight cable. No null modem is needed nor crossover of pins. This version of the wj200 driver won't use Modbus over ethernet, it's serial only. Since libmodbus supports ethernet, theoretically support for this could be added without too much trouble.

On the wj200 front panel, you have to edit a few parameters in the C registers. I specifically checked the unit's modbus address, made sure modbus communications were selected, changed speed to 9600 bps and verified that parity and word length settings were what was expected (8N1). I also changed the A registers so the unit would accept commands for frequency and run from modbus.

Note that if you're new to the wj200 and you can't get the front panel to display the register you want to change or it won't let you change it, you need to change the software lock setting - look in the wj200 manual to find the register for that, it'll be one of the ones you can see. Also, there's a software download for windows that lets you configure the wj200 with a simple GUI via USB. It's worth using for initial setup of the inverter, especially tuning it to match the motor and ensuring that the motor's "forward" and "reverse" settings make sense from the VFD's perspective.

To use the driver, put this in your .hal file:

loadusr -W wj200_vfd
setp wj200_vfd.0.mbslaveaddr 1 # or whatever your unit address is

Note that although you can use the -Wn and -n parameters with this statement, they don't work and won't tell you why. If you use -Wn what will happen is that the HAL startup will hang (printing ..........), waiting forever for a component that doesn't exist to be ready (because -Wn specifies a name to wait for and -n doesn't actually change the name... you have to use -W only.

I haven't tried loadusr -W spindle wj200_vfd, it should work. Multiple instances of the component seem to be allowed, but I don't have multiple wj200s. Note that multiple wj200s would have to be on the same rs485 bus and serial port unless you edit and recompile.

With -W, HAL loads the component and waits for it to signal that it's ready. I'm not completely straight on the semantics of -W yet, but I believe for the wj200 component to be ready it has to establish communication with the VFD. In order to do this, the RS485 connection has to work.

In addition to the serial connection being set up and wired correctly, you *have* to set the mbslaveaddr parameter with the second line listed above. If you don't set this, the driver will loop forever doing nothing waiting for it to be set. The default address won't work, for good reason.

I don't have a good suggesting for testing the wiring without starting linuxcnc... I got everything hooked up and it "just worked" more or less. I know the mb2hal component supports better logging, so possibly using that component to try to connect to the vfd would let you debug your serial connection. Libmodbus (which you will have installed to use this version of linuxcnc) also comes with example programs that you could edit to contact your vfd as a test.

So, assuming you start linuxcnc and the component loads and the usual GUI comes up, then the driver is successfully talking to your vfd. If this happens, the VFD will immediately display an error message like "E12.7". This means the vfd is in "trip" mode, or shutdown. The driver does this whenever the vfd isn't enabled, to "safe" it. Whenever you don't have the component's enable pin set to "TRUE" the vfd will be in trip mode and display this error.

At this point you should be able to see the components, pins, and parameters of the driver in your "show hal configuration" window. You can test to see if everything works as expected by manually entering:

setp wj200_vfd.0.enable TRUE # enable vfd, bring out of trip mode
setp wj200_vfd.0.requested-frequency 60 # Set frequency to 60 hz

Note: The following starts the spindle... be ready for it to spin and possibly hurt things and for power wires to zap people before you type this:

setp wj200_vfd.0.run TRUE

to turn it off:

setp wj200_vfd.0.run FALSE

to reverse direction:

setp wj200_vfd.0.reverse TRUE

(note that you can reverse direction at full speed... the vfd will slow to a stop, then reverse)

After this you can implement wiring in HAL to connect the vfd to your spindle controls. This is next up for me. I'm going to first implement a connection to my E-stop chain so the spindle stops properly along with the enable connection to un-trip the vfd at power on. After that I'll be setting up a watchdog to use the "watchdog_out" bit so communications problems with the vfd get detected and alarm handling to use the "is_alarm" bit. Once those failsafes are implemented then I'll connect the basic direction, speed, run, and at_speed bits.

Erik

A couple of quick notes to add to this...

First, I found out from the source code that there's some ability to set comm parameters like bps and parity (I think) in the loadusr statement, or at least the code seems to be there. I don't know enough about the minutiae of loadusr or writing user space hal modules to know if they're usable. It does not seem like you can set which port you use, so you're stuck with ttyS0 without a recompile regardless.

Also, the existing driver works for spindle control, it's a pretty simple set of net statements to connect it to motion.spindle I'm using at the moment. I did find out that the speed setting for the driver is in hz (frequency) rather than rpm, and no provision is included to convert an rpm setting. It's a pretty basic driver. It does work, however.

I'm considering adding some code to it to do the RPM conversion, maybe reading the motor parameters from the vfd as part of the initialization of the driver.

Can anyone who's dealt with the code point me at documentation for including configuration statements in the hal files? I would think there'd be a way to include a custom named section for a user space driver with parameters and such, so not so much has to be passed on the command line.

Erik

Yes, that's what I wanted to know. Should be very helpful, thanks.