Problem with MB2HAL configuration

Hi all,
I have been trying to use MB2HAL to get a motor current feedback from a servo drive through the modbus rtu protocol but I dont see any HAL pins being created in the LinuxCNC when I open the HAL meter. Do I have to create the pins manually? If yes then how do I do it?

What I have done so far is:

1. I added this line into the [HAL] section of the main machine configuration .ini file

2. I created modbus.hal file in the same directory and a put this line into it
3. I created the mb2hal_config_file.ini file in the same directory and I put my modbus transaction configuration into it. It is possible I configured the transaction incorrectly but I thought that I would at least be able to see hal pin for the modbus transaction.

Here I attach my modbus configuration .ini file

Here is a link to the servo drive modbus protocol manual:
pdf.directindustry.com/pdf/adtech-shenzh...n/114531-657678.html

I really spent a lot of time trying to solve the problem but I don't know much about HAL and how it works. I would be grateful if somebody could help me solve this problem.

Try this exactly as typed:

Will create:
Component Pins:
Owner Type Dir Value Name
8 float OUT 0 mb2hal.torqueD1.00.float
8 s32 OUT 0 mb2hal.torqueD1.00.int
8 u32 OUT 0x0000005C mb2hal.torqueD1.num_errors

I used halrun in one terminal to load the ini file & halcmd show pin in a second terminal.
If you are using a run-in-place install you will have to load rip-environment in both terminals. If you are using the iso or installed via debs you don't have to.
Obviously I don't have any hardware connected to ttyUSB0 so can't test the transactions.

Thank you.
I tried your solution and I can now see the pins using the halcmd show pin command but looking at the terminal where I loaded the file I see the following transaction failure message
I think that maybe I have done the wiring incorrectly as the manual is a little confusing.




I have set the communication type parameter on the drive to operate in RS-485 and I set the same baud rate as in my configuration file.

The USB-RS-485 adapter I got is just a 2 wire same as the one on the picture below


I connected pins 4 and 6 to B(D-) terminal and the pins 5 and 7 to A(D+) terminal. I left all the remaining RJ45 wires disconnected.
Is this the correct way to wire or did I make a mistake there?

I think that you probably only need to connect to one of the RS485 pins. (But you might well find that both D+ and D- pins are internally connected and are duplicated only to allow daisy-chaining)

You might need to connect the GND to the same GND as the controlling PC.

Thank you. I have the wiring problem solved now. The PC is now communicating with the drive.

Does anybody know how to change the register address accessed in the MB2HAL transactions?

I tried different values of FIRST_ELEMENT which I thought was the register address because it is described in the comment as "The first element address" but it doesnt seem to change anything. My ModBus transaction seems to be accessing the same 0000H register and I know it is this register because I keep getting a feedback with the value 3018 which I know for a fact is stored in this register.

I've used this before, may want to give it a whirl to check comms and that between pc & servo drive......gives nice debug info
github.com/ed-chemnitz/qmodbus/
when experimenting with modbus over tcp (also supports RTU so can test serial)

I have qt4 installed on my system and it compiled ok, I'm running stretch amd64, appears to open ok....no seg faults, unfortunately haven't been able to test......can't find my arduino slave ATM.

If you build it, be sure to note the .. after qmake command, I almost missed it :laugh:

A search for "modbus master simulator" will bring up other hits, haven't done much looking into a slave sim but I'm sure there is a few around. Maybe this might be an option www.modbusdriver.com/diagslave.html

Problem solved. Turned out I totally missed the fact MB2HAL takes values in decimal form while the register address is hexadecimal. Converting the hex form of register address to decimal solved the problem

dom96 wrote: Problem solved. Turned out I totally missed the fact MB2HAL takes values in decimal form while the register address is hexadecimal. Converting the hex form of register address to decimal solved the problem

Well done sir.......nothing like a simple fix

Something to keep in mind tho