Mesa modbus and pktUart

persei8 wrote:

I did find that doc and have read it several times. I did also set a pin to control motor on/off (u32   IN     0x00000000  vfd_modbus.00.motor) but I did miss a pin.
 

U32 seems wrong for a motor on-off signal. And are you sure that Modbus command 6 is correct?

I would expect the .mod file to have something like:

{HAL_BIT,   5,   0x2000, 1,     "motor"}

On the Huanyang GT series, to turn the motor on, you write 0x01 to register 0x1000. To turn it off, you write 0x05 to register 0x1000.
The docs state "In addition to the pins configured in the definition file, each module will create the following pins for each instance of the driver:"
I find that those HAL pins are not created. From the generated C file, I see there are a couple of conditions where the creation is skipped but don't know enough about it to figure out exactly why. There's something it doesn't like about retval in the rtapi_app_main function.
In my postgui HAL file, I instantiate the component with: The module is created with the pins defined in the channel descriptor file, but the additional HAL pins are not created.
Jim

persei8 wrote:

On the Huanyang GT series, to turn the motor on, you write 0x01 to register 0x1000. To turn it off, you write 0x05 to register 0x1000.

You might find this HAL component useful, in that case:
linuxcnc.org/docs/2.9/html/man/man9/enum.9.html

The docs state "In addition to the pins configured in the definition file, each module will create the following pins for each instance of the driver:"
I find that those HAL pins are not created.

fault and last-err should be created as pins. The others are parameters. These can still be "setp" to values but can't be netted. The manual page needs an update. you should see them with halcmd show param ?

There's something it doesn't like about retval in the rtapi_app_main function.

In that case it won't load at all?

So I removed all the nets for those extra pins and set values via setp. This means they can no longer be set programmatically. Not sure that's really a problem but it does set them in stone, so to speak. This brings me to a couple other questions.
Why does the module want a motor pin when I set the motor on/off by writing a modbus register? What does it do?
Is the last-error pin an index to a list of error messages? If not, what is it?
Jim
 

Generally LinuxCNC provides a bit-type output to turn on and off the spindle.

It seems that your Modbus driver doesn't really support that, so I think what you currently have it probably OK for the driver.

To send the 0x1 / 0x5 to the modbus driver you can either use the enum component I mentioned, (loadrt enum enums=E;;start;;;;stop should probably work) or maybe use a mux component if you prefer.

Are there any other values that can be sent to that register to do other things?

I'm using a user space HAL component to drive the mesa_modbus component. It receives spindle.0.on from linuxcnc and converts it to 1 or 5 for the modbus register. Register 0x1000 does other things, none of which I need. It would be easy enough to replace the userspace component with the enum component. I'm beginning to think this mesa_modbus component is intended to run as a standalone modbus vfd driver? 

persei8 wrote:

I'm beginning to think this mesa_modbus component is intended to run as a standalone modbus vfd driver? 

I am not sure what you mean by that. All that it does is convert HAL pins to Modbus messages and Modbus messages into HAL pins. 

Which (along with the enum component) should be enough for most VFDs. 

There is also the dedicated component for the HY GT VFD but that can't use the Mesa UART connection. 

Actually, I need to keep my user space component because there's another register operation that needs to be done and there's probably no prebuilt component for that. To set the motor speed on this VFD, you set the percentage of the programmed maximum speed. It also checks that the commanded speed is within the specified range between a minimum and a maximum. All that aside, I think it's working. I just need to switch the modbus wires over to the 7i96.

It is working. Then I got the idea that I should replace the userspace component, which is written in python, with a realtime HAL component. It compiled and installed OK and I can see it in halcmd and all looks good. However, with linuxcnc running, I get an error: I looked at a bunch of other component source files and I don't see what I'm doing wrong.
Jim
 

have you done addf and loadrt?

Shere your code