Delta MS300 VFD, RS485, RPI4, QTdragon, getting it to work

I'm trying to get my VFD to work via RS485. I've tried al kinds of things, one thing i know, is that is does communicatie via /dev/ACM0. I used the standard drivers like GS2 for that, but those drivers don't seem to have the right communications with my VFD.

I looked at M2BHAL and classic ladder, but that is just to complicated. Thats hard to say...
I don't know anything about modbus, but I do understand DMX (for lighting, that's a similar protocol)

I also tried VFDMOD, that looks very easy, but, there is no ARM64 version.

Sometimes I wonder why I started to use linuxcnc.... but I've come so far, I've learned a lot and my cnc is running but not the way I want...

To start with, which route do I have to take to get my VFD running on my Linux2.9/RPI4 arm64 machine?

In this topic there is information about adresses. forum.linuxcnc.org/24-hal-components/387...modbus-rtu?start=100

I've tried vfdb_vfd too, but the reverse and forward pins are missing.... ( linuxcnc.org/docs/html/man/man1/vfdb_vfd.1.html#PINS )


 

okay... I'm reading about modbus, that helps. mb2hal is the best option I guess... future proof... I'm greating a config file now. Is there an artical about the relation between mb2hal and a vfd manual? That would be nice....

I don't think there is any specific standard for VFD modbus. I was lucky, the day I was going to resort to PWM spindle control, somebody posted a config for VFDMOD here on th eforum and it worked!

There should be some modbus data in your VFD terminal

VFD's are all different, but modbus has a cenrtain standard of data structure. I've copy paste a lot too, but I want to know what I'm doing. Only then I can create beter configs and fix things.
I'm now trying to figure out how I have to use the read/write/register/coil settings. It's part of how modbus in general works, but I don't understand how it's related to the VFD manual. Reading and writing is obvious, but coils and registers are getting more complicated, especialy when there are multiple settings on one address...

I'm not sure of the MB_TX_CODE settings. And what about the new version 1.1 settings? The goal is to use as less as possible conversion functions in the hal file. And I just want normal readable names, version 1.1 should give me that option.

This is from the manual:

This is what I have now. I'm I doing something wrong? Can I do things beter to make it more logical (for a non-IT person )?
 

usefull information I got from another topic:

The names and types of pins created by Mb2hal is determined by what you put in the Mb2hal ini file. Specifically the transactions that you define there. 
There are at least 5 different transaction types that can be used. And these  determine if the pins created are boolean, floats, # inputs or outs.
fnct_02_read_discrete_inputs: creates boolean output HAL pins.
fnct_03_read_holding_registers: creates a floating point output HAL pins. also creates a u32 output HAL pins.
fnct_04_read_input_registers: creates a floating point output HAL pins.also creates a u32 output HAL pins.
fnct_15_write_multiple_coils: creates boolean input HAL pins.
fnct_16_write_multiple_registers: creates a floating point input HAL pins.

The number of hal pins created by each "transaction" is determined by the number of "elements" in that transaction.

The names of the hal pins created are the default name:
Example pin name for the 1st transaction 2nd element would be:
mb2hal.00.01 (transaction=00, second register=01 (00 is the first element))
or the transaction number can be replaced by name you define with
HAL_TX_NAME=name
Would give: mb2hal.name.01

and:

Setting up modbus communication for a new device you aren't familiar with is always a pain. (even when you do know what you're doing.) The documentation for the device is almost always universally awful, worse if it is Chinglish. From the looks of it your life is going to be made difficult by the fact that according to that document the drive only supports modbus functions 3 and 6. So you won't be able to address individual bits directly or read/write to multiple addresses. The first issue will result in you having to set up hal components to translate bit io to and from S32 integer numbers. The second problem will make you have to set up individual transactions for each different register you may need to access on the drive. That can lead to slower communications, especially if you must communicate with multiple devices.

So for example you'll need to set up a transaction that writes to 1000h (That would be 4096 in dec and I think the address number you'll need to use in your modbus ini file.) But you will have to send to that transaction an integer number representing the state that you want the drive set to, fwd=1, rev=2, stop=5... One of the mux hal components might be useful for setting the value you want for the appropriate bit inputs. (It doesn't look like simple binary bit/coil translation will work for this register.)

 

I'm just talking to myself, that helps too

So, it depends on your VFD what kind of read/write types are supported. In my manual there is no paragraph about that, but there is something that looks like it. They are talking about the following functions:

fnct_03_read_holding_registers (03 = 0x03)
fnct_06_write_single_register (06 = 0x06)
fnct_16_write_multiple_registers (16 = 0x10)

So, that's where I have to deal with.
I'm afraid that I need conversions in my HAL-file then....
 

Maybe I want to much....  I found this on the printnc discord. I guess I have to do it like this.... Although my brain says: that can't be in 2024!!! Mux-ing and scaling should be done bij mb2hal, but that's my opinion.
 

Hi Calysto,
before communicating with VFD via Modbus I would buy a simple modbus input/output relay and start practicing modbus and MB2hal.

Do you know if is it possible to position spindle with MS300?