Machsupport Forum
Third party software and hardware support forums. => Modbus => Topic started by: mvcalypso on January 20, 2009, 02:46:10 PM
-
Hi Guys,
I'm looking for some mach 3 modbus info.
I have a new mill I've interfaced to mach. The spindle has the usual 0-10v input on the VFD to control spindle speed, I currently have that hooked up to the PC via an SD to 0-10v board. This results in a Digital (mach) to analog (SD to 0-10) to digital (VFD 0-10 to speed) chain – which is rather nonlinear and hard to calibrate.
The manual for the VFD I'm using says it also has an rs-485 input and accepts what appears like it may be modus as a command structure. So I thought that a better way might be: mach mobus serial out (digital) to rs-232-rs-485 level conversion to the vfd rs-485 input. This would eliminate the analog conversions from the path.
I'm not real familiar with the modbus protocol so have been reading stuff off the web.
I think the vfd looks like a modbus slave and I think mach acts a mod bus master?
What I'd like is a pointer to detailed info (messages, sequences, formats etc) on what mach puts on the serial port when modbus serial support is enabled. I'm particularly interested in messages resulting from M3, M4, M5 and S codes. (Note that I'm not looking for the Holman mod-io info, which I have - right now I'm trying to figure out if I could do a PC serial port direct (other than sio level translation) to vfd hook up approach).
Is there a doc that details how one would interface a modbus device to mach via the serial port?
Dave
-
http://www.modbus.org/ is where MODBUS protocol is described, you can download the documents.
-
I have a question from my side:
If I want to build a ModBUS device, what MODBUS data types are to be supported?
e.g. there is a simple source code that I could use, but it supports 3 and 16 (read registers, write multiple registers)
In fact I would not like to use "coils" for discrete inputs, but rather use a register for multiple inputs / outputs.
With this I could save lots of MODBUS bandwidth, but of course the MODBUS plugin has to be able to support this...
Any hints regarding this?
-
Hi Guys,
I have a new mill I've interfaced to mach. The spindle has the usual 0-10v input on the VFD to control spindle speed, I currently have that hooked up to the PC via an SD to 0-10v board. This results in a Digital (mach) to analog (SD to 0-10) to digital (VFD 0-10 to speed) chain which is rather nonlinear and hard to calibrate.
I'm with you - with even cheap VFD's supporting RS485, direct control over the VFD is the way to go. You get less complexity (on the hardware end), more accurate control and the ability to do things like monitor load and error codes. I'm suprised more people don't seem to do it this way... that was until I ventured down the path to figure out how to get Mach3 working with my Modbus VFD. Long story short - it took about 20 hours of research, testing and learning about Mach3 "oddities". In the end I did get it working and it works pretty good. Not perfect but it works for me.
Let me know if you have a specific question and I can see what I can do for you. I've got a Teco CV-2003-H1 from FactoryMation I'm using.
-
I'm waiting on my spindle and VFD but see things the same as you guys. Why have mach pulse and put a freqency to voltage board in the mix when direct comms are possible? My VFD is a Huanyang HY02D223B with limited docs on the rs485 interface. Can you post how you set yours up so i can avoid probably 400hours of research :)
Cheers
Mark
-
Mark -
Here you go. Be aware that this may not be the best method but it seems to be working for me.
The code below works with the following VFD:
http://www.factorymation.com/s.nl/it.A/id.5578/.f
TECO 7300CV AC Drive, 3 HP, 230V 1 PH Input, 230V 3 PH Output, 10.5FLA, IP20, Frame 2 (JNTHBCBA0003AC-U)
Contents of Macropump.ms1:
Dim TspinRPM As Integer
If TSpindRPM = 0 Then
SetParam("RPMOverRide",1) 'allows us to over-write the TRUE RPM DRO
RunOnce = 1 'set the flag so this code doesn't run more than once in a session
End If
'Spindle Speed Routine
CurrentSpindleOverRideSpeed = GetOEMDRO(202)
FinalOutputInHz = CurrentSpindleOverRideSpeed * 1.6695 'this is used to correct for actual speed
SetUserDRO(1001,FinalOutputInHz)
'Spindle Power-up/Power-down Routine
If GetOEMLED(164) Then 'check to see if the spindle is moving CW
If Not GetOEMLED(800) Then 'check to see if we are in reset
If GetUserDRO(1001) = 0 Then 'the spindle is at zero rpm,
SetUserDRO(1001,10000) 'Set the spindle to 100hz
Code "S12000" 'set the spindle speed DRO to default off zero
Sleep 1000
Else
SetUserDRO(1000,1) 'start spindle
SetOEMDRO(39,CurrentSpindleOverRideSpeed)
End If
Else
SetUserDRO(1000,0)
End If
Else
SetUserDRO(1000,0)
End If
'Spindle Error Control
CurrentVFDErrorCode = GetUserDRO(1002)
Select Case CurrentVFDErrorCode
Case 0
'nothing is wrong
Case 44
'Modbus communications error
Case 11
'Over Current during accelerating
DoOEMButton(1021) 'hit the reset button
Message("SPINDLE: Over current during accerlation")
SetUserDRO(1000,8) 'reset spindle
Case 11
'Over Current during decceleration
DoOEMButton(1021) 'hit the reset button
Message("SPINDLE: Over current during deccerlation")
SetUserDRO(1000,8) 'reset spindle
Case 30
'Can not start spindle at 0 RPM
DoOEMButton(1021) 'hit the reset button
Message("SPINDLE: Cannot start spindle at zero RPM")
SetUserDRO(1000,8) 'reset spindle
Case Else
'trap
DoOEMButton(1021) 'hit the reset button
Message("SPINDLE: Other error #" & CurrentVFDErrorCode)
SetUserDRO(1000,8) 'reset spindle
End Select
'Spindle Load Update Routine
CurrentSpindleLoad = GetUserDRO(1004)/10
SetUserDRO(1100,CurrentSpindleLoad)
See the attached "MacroPumpInterface.brn" Brain file.
You will also notice that I used UserDRO(1004) to store the current spindle load. I then use that on a modified screen to display the load.
Hope that helps.
david
-
Thanks David.
It's always easier to get a start once you can see how others have proceeded.
Cheers
Mark
-
What do you do if you want to output serial to a non-standard modbus?
The structure of how Mach makes up a modbus string is unfortunately not how I need to communicate with my Huanyang VFD which has a structure of a single byte address, a single byte function (which don't adhere to modbus standard), a single byte date length indicator, 1,2 or 3 byte data depending on the Length specified and then a two byte CRC.
I can fully control the VFD via the usb port (usb to rs485 adapter) using some VB scripting..... how should I best proceed to replicate this control within Mach?
BTW My programmer friend has posted over on the zone the test app (search Water cooled spindle step by step) if anyone wants to experiment and has one of these VFD's
Cheers
Mark
-
Ok I take some of my lasty statement back.
The Huanyang VFD does (for the most part) fit the ModBus standard.. as I've read it from www.modbus.org . However Mach seems to force you to enter a StartC or Modbus address of 2 bytes as part of its framing rather than leave this as part of the Data field.
RTU framing as per Modbus is:
1 byte slave address
1 byte function (which is workable with the Huanyang except 02 and 03 are seen as writes in it rather than reads)
N x bytes data
2 bytes CRC
Can you configure Mach to act this way or are you forced to enter the fields as it desires?
Ie. if the Modbus Var(start reg) and # of registers was just left as part of the data field n bytes long
It seems as if Mach has predefined the string based on what one board may need rather than a generic Modbus standard.
What am I missing? Or am I setting it up incorrectly. Is there another way to serially communicate out of Mach rather than using the inbuilt Modbus (ie do I need to write VB scripts for everything including the CRC calc)
Help!
Thanks
Mark
-
Hi Mark,
If the message format is as below, then it does not meet the modbus spec. Mach3 uses a Modbus compliant library. There is no way to make it non standard.
1 byte slave address
1 byte function (which is workable with the Huanyang except 02 and 03 are seen as writes in it rather than reads)
N x bytes data
2 bytes CRC
I'm thinking of making a small converter board that takes in Modbus on one side and outputs the Huanyang protocol on the other.
Cheers,
Peter.
-
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
-
Hi. Hi. I too have HY02D223B. The same I can not start ModBus for work. It will be possible to hope that this problem is solved? ???
-
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
Edit:
I just looked over everything and I've been reading the posts wrong, ignore me.
-
Hello folks,
Sad to hear about this incompatibility issue as I just got my Huanyang and had in mind to run it via Modbus. I don't feel like getting into a hassle with non-standard devices so I am now thinking of buying another inverter which supports Modbus. Before that I think it would be a clever idea to be sure down to the detail how a Modbus compatible inverter is run and how it is run from Mach. So, can anyone point to an article(s) which describes this whole process and what is expected from the inverter and what perhaps is needed to be done (programmed?) on Mach side?
Thanks,
Risto
-
Hi Guys
I was making the same mistake.. (read the messages after the one quoted)
You need to see how the data is structured ...
http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf
I'm no modbus expert either but this is how I see it
It is a protocol so it describes how (rs485 rs232 etc) messages are sent and what fromat they are sent in (address, function etc) but not the actual data therein. so I doubt that you could just swap two different VFD's and not make any changes to your code. IE on one VFD PD001 may mean start while on anotehr it may mean stop etc.
The Huanyang VFD is a poor attempt at meeting the protocol and is flawed. Some are trying to address this with the manufacturer but its a very long drawn out process and may not happen. Two things to remember ... 1. its probably preprogramed into the pic chip and not flashable and 2. many applications are stand alone and don't use Modbus.
The Plugin is a "work around" and is a viable solution and slightly more elegant IMHO than using a analog input. The fact that we are using the VFD to drive a spindle means many of the fancier features (ramp ups and downs) are not needed so we are only using a small number of parameters .
Start
direction'
speed
stop
and read backs for actual speed and current draw.
As the saying goes "you get what you pay for" and a fully complient VFD with all the features would I think be far more expensive than these units with their :flaws"
Cheers Mark
-
Thanks Mark & all,
Do you have any news about the schedule of the plugin?
/Risto
-
Matty Zee has just had a kid so its a bit on the back burner for now but he is just doing some final tweaks. Last thing any programmer wants to do is release too early and then have to put out fires left and right. What I can say is that the version I have been testing so far starts and stops the in response to M codes in a file and reports back the current (although its scalled at the moment TBF) the VFD is drawing. Speed is also settable. so its 98% there.
Reverse direction has not yet been implimented and only limited testing has been done so far.
Keep an eye out on the plugins threads I'm sure you'll see it pop up there fairly soon.
Cheers
mark
-
...
Keep an eye out on the plugins threads I'm sure you'll see it pop up there fairly soon.
Cheers
mark
OK, thanks for that.
What comes to mind is that once the plugin is ready it could be a minor task to tailor it to run other - Modbus compatible - inverters as well.
/Risto