MODBUS control for Delta VFD-M

Hi, I'm refuctoring the spindle control on my CNC router to use MODBUS RTU. I've successfully communicated with the VFD from the LinuxCNC PC using the ASCII protocol and some code of my own, but it's not a proper HAL component. I found the vfdb_vfd component and attempted to use that, but obviously a number of the registers are different, and it won't run.

I grabbed the LinuxCNC source and tried making some changes and rebuilding the component, but things are segfaulting - presumably because of binary differences/library incompatibilities or such like. I also tried rebuilding all of LinuxCNC from the source, then realised that I would have to update my settings due to the joints/axes separation and felt like I was changing too many variables at once. I did try running it after backing up my config but that didn't work either.

So:

- What's the right way to build just a single C/binary userspace HAL component for an existing stable LinuxCNC installation?

- Would it be a good idea to try to modularise the code for the Delta VFD models? Or even MODBUS RTU VFDs in general? I realise I could just copy the existing component and modify from there, but there's quite a bit of commonality in the registers between the VFD-B and VFD-M.

- Should I try to flesh out my existing code to make it a userspace/loadusr component? It's written in Tcl, and I've seen some Tcl code around the LinuxCNC project, but wasn't sure if there were bindings for the HAL side. Could/would I use haltcl for this?

Thanks!

Sorry, I meant to post my earlier message in the HAL forum! It was a long day and I had limited time to work on the machine.

I tried some more sensible things tonight (including using "git checkout" to roll back to the right version of the source before rebuilding the component), and have managed to get some useful Modbus RTU communication between LinuxCNC and the VFD. Still no frequency control or commanding the operation of the drive, as it looks like I'll need to change more than just the location of some registers. I've added output pins to the component for VFD temperature and bus voltage, though. I'll see if I can get something working and presentable to add to the repo.

Modbus communication failed at one point while testing, after I'd manually turned on the spindle motor. I suspect EM interference - I had significant issues with interference on the home sensors and stepper control signals earlier in testing. The USB to RS-485 adapter actually disconnected completely and reappeared as /dev/ttyUSB1. I have some shielded VFD cable that I hope to install some time and see if that helps (I also think the ground wire in the original spindle motor cable is not connected at the spindle end). Anyway, onward...

More progress tonight: after further hacking of the vfdb_vfd.c code and some HAL troubleshooting, I have speed and on/off control of my spindle VFD. The EMI problem will definitely need to be addressed, though. I'd hoped that the reconnection code in the component might work if I used the stable /dev/serial/by-id/... path instead of /dev/ttyUSB0, but libmodbus doesn't seem to like that. I also found that the polling timing in the original vfdb_vfd.c wasn't working properly (it always seemed to run as fast as possible).

I would like to tidy my code and perhaps integrate it into a more modular component for various VFD models, if that would make sense (incl. docs, of course). I don't know if such a component should be limited to just Delta VFDs (I see the ancestral vfd11_vfd is for a Toshiba-Schneider model).

into my modbus pc QT HMI interface I use with success with toshiba VFxxx the device .... is quite good DA-70xx is the most rugged and durable ... use them in industrial environments with moisture and dust.
when you are realised the connections dip the terminals in the insulating gel into a small box. The result is perfect.

About shield pin on vfxxx... my supplier up to 100mt tells me I can do without ... At my part I connect it on DA-70xx because there is a specific pin.

Thanks for the suggestions on the RS-485 adapter. The one I'm using at present is a Jaycar XC4132 , which unfortunately doesn't provide a terminal for shield ground. I don't believe it's galvanically isolated either (not sure if that's a big deal or not). To be honest, the cabling I'm using for this initial testing is completely inappropriate, as it's not even twisted-pair (just some spare telephone cord that had the right connector at the end already)! I was thinking I could attach the signal cable shield fairly easily to the chassis of the LinuxCNC PC, if the interference persists after upgrading to shielded VFD cable and attaching the PE ground on the (Chinese) spindle.

Since I have a few days to spare, I'm going down the rabbit-hole of writing a Modbus library in Tcl so that I can write a userspace component a bit more easily.

there is a libmodbus very useful for these ..... goto libmodbus.org ... is quite simple ...
Here my simple modbus connection uspace lib example....

In new master is not possible use it as singleton ... so you can use the out and in pin as : rtuserver.0.xxx => halui.machine.on for ex.

Is not well tested and when I test it better I write a guide-post with rtucustom/tcpcustom.hal + rtuserver.comp.

Obviusly you can use the code adding some register for pilot VFxxxx ... sorry but I have just a cpp qthread-class on qt app for pilot my VFxxx.

hoopsss.. I see you would write Tcl hal modbus so my suggest is not useful ...

Regards
Giorgio

One issue that was making me reluctant to use libmodbus was that it didn't seem to allow paths such as /dev/serial/by-id/whatever. That was a problem because the EMI was causing the OS to reconnect the USB-to-serial device every so often, and it would come up on a different device name, and communication would be lost. The /dev/serial/by-id/ path on the other hand is stable. I guess I could write some udev rules to stabilise the device name.

Tonight I rewired the RS-485 connection between the PC and the VFD, and it seems to be even more susceptible to EMI. The cable is Firstflex FT2002ESCS and is specified for RS-485 use. I'm using only one twisted-pair, as the USB-to-serial adapter seems to require that for RS-485. The shield is grounded at the transmitting side only, to the PC chassis. I have a 120-ohm terminating resistor at each end of the cable, but no biasing resistors. The PC's USB-to-serial adapter and the VFD are the only two devices, and are basically at the ends of the cable. With the PC powered on, the + and - terminals read about 2.5 V each. Communication with the VFD works OK with the spindle motor off, but with it on, there are errors every second, and Linux reconnects the USB device every few seconds.

It wasn't that bad before, and that was using unshielded untwisted phone cable and no termination! Could it be that the USB adapter and/or the VFD have internal termination?

Is not emi problem..... or maybe ..... for shure is a old problem on all usb connection on all deb so ..... for solve these you must force to load your specific usb device at boot from so. The problem is more evident when more power was used from your usb device. The same problem is more evident on usb3 .... less on usb2 .... DAxxxx device is more trasparent to these ..... win not have these fault type....

But you not have a Vxx toshiba modbus manual? The frequence ha it own register... other command single bit....


Regards
Giorgio

Any how .... fol libmodbus:

You are in right: usual intallation of ubuntu/mint of linuxcnc have some problem. But I SO related not linuxcnc. Ubuntu repo it has an old version of libmodbus that is not so "compatible " with new Linuxcnc and new Rtai.

For solve these when you try to compile linuxcnc ... first unistall standard libmodbus present on your pc, than install the last one from libmodbus.org, install other pgr or module if you need, than compile Linuxcnc.

After these you have not problem with linuxcnc, ubuntu/mint and libmodbus path.

Important use ldconfig and pkconfig for create the right link.

Regards
Giorgio