Hi Peter

It is like that. But how do you get Mach to talk like that? When I put a port sniifer on what Mach outputs and use the test routine all that I can seem to get is:

1 byte slave address
1 byte function
2 bytes start address
n bytes data
then 1 byte = number of registers if its a read
2 bytes CRC

What I seem to be getting hung up on is how to configure modbus without all the extra bits.

I'm toying with the idea to create a plugin (not sure if thats the right way or not) but would prefer to just output bog standard modbus strings. You shouldn't need a hardware translator.

Can you point me in the right direction to learn how to config mach this way? I've read and watched the tutorials but thay all seem to be directed to setting up for your board or PLC that likes all the extra stuff.


Cheers

Mark

Hi Mark,

I just edited my last message.  I meant to say that if the message was as you described, then it is not Modbus compliant. You cannot change the format of the modbus messages that Mach3 sends.

Modbus requires you to provide the start address and the quantity of registers/coils being read.  You can't get around that in Mach3

For whatever reason, Huanyang  have not implemented the protocol correctly. It may have been a translation problem.

If you look at the Modbus config page for the Modbus I/F with Plugin support, you will see the required fields.

Let me know if that is not clear.

Cheers,

Peter.

Ok that makes more sense.

I am curious why you say this is not modbus compliant as I was quoting verbatim from here:

http://www.modbus.org/specs.php

See attatched pic of page 14

Cheers

Mark

I might have answered my own question...

Just skimmed thru the application protocol and in there it specifies the data stucture as you describe.... Oh well back to writing a plugin.

Cheers

Mark

Hi Mark,

All is clear now. Your making the same mistake that the engineers at Huanyang  have.

Yes the spec says the modbus serial pdu contains

Address
Function Code
Data
CRC

BUT, you need to see what the definition of the Data field contains for each function code. For that you need to look at the document

http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

For instance Function code 03 (Read holding registers) on page 15 shows the Data field contains 2 sub-fields as shown below.

Data.starting address        2 bytes  =  0x0000 - 0xFFFF
Data.quantity of Registers  2 bytes =  0x0000 - 0x7D


And, the Data field in the response to this contains;

Data.bute count       1 byte         =  2 x N
Data.register valuess  N x 2 bytes  = 0x0000 - 0xFFFF

where N is the quantity of registers.




Cheers,

Peter.

Thanks Peter... its all unfortunately clear now (darn!... never can be easy can it!)

I have my suspicions about these VFD's being either surplus or from a failed company as I never did find a direct link to Huanyang only chinese auction sites.

But on the off chance I'll see if Chai (ebay seller) can pass the info onto them. After all its a relitively simple s/w change in their flash rom or pic to fix and they would be well advised to adhere to the spec if they want broader sales. Wouldn't hold my breath though as many have found they are missing bits of hardware along with the s/w "features" such as the circuitry to impliment braking resitors.

At this point I'm working on the idea of creating a plugin that will "convert" Mach talk to huanyang talk. ie M3 triggers a bit of C++ to output the correct string via the serial port. Now I'm speaking from complete ignorance so i have no real ideal how I'm going to do this but it seems feasible.

Cheers

Mark

Hi Mark,

I am considering buying a HuanYang VFD. Had been collecting some information on it and came across this thread.

I'm curious, have you got it solved yet?

Thanks,
Daniel

Nope not yet... been too busy doing other stuff.

One of the guys on the zone forum who has one of these and lives in Hong Kong so the latest idea is to wait till he I comfortable with how Modbus should work then he can talk directly in chinese to the manufacturer and see if they can be convinced of how important it is for them to become ModBus compliant.

I've not had a chance to look at this stuff for awhile (also kinda hoping some C++ guru would take the bait and write the plugin for us)

Cheers

Mark

Hey Mark,

I remember posting on a thread on CNCZone about this same thing. I was the one suggesting a USB/RS485 protocol converter (not sure if you remember me).
Anyway, i gave up waiting for someone else to write a plugin and have started writing one myself (not the protocol converter, a proper plugin). Its going pretty well so far and hope to have a beta version by the end of the week. Are you interested in helping me test it?

let me know if your interested.

Cheers

Matt

Hi Matt

Been AWOL for a while from the machine doing a silly yacht race but now am gearing back up to get my beast up and running. I would be very happy to help test or anything else to lend assistance as I think this is really te way to go (plugin)

You can send me a direct email at my username at gmail

Cheers

Mark