Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: davidbgtx on October 01, 2015, 10:28:12 AM
-
Put an ECOMM100 in my Do-More rack to program do-more through and talk to HMI and other Modbus/TCP connections on the LAN (WINPLC's, Kepware).
Using Do-More internal port for communicating to remote rack. I can't get MRX or MWX to work on the LAN (to my WINPLC's). MRX/MWX works fine to WINPLC's if the Do-More internal port is connected to the LAN.
So can you not use MRX/MWX "through" the ECOMM100?
-
Not directly. You can get the ECOM100 to do Modbus comms through DLRX/WX, but you have to configure it in the ECOM100 peer table.
We really wanted to do it directly, but the Do-more instruction was somewhat incompatible with the way the ECOM100 did Modbus.
-
Have set up peer link table for the ecomm100 (in the client rack). I have been able to read data from another do-more (server no ecomm) by using publish in the server and DLRX in the client (see ecomm 1 pic), that works. I can't read control relays on the server, always get error bit (see ECOMM 2 pic). Can you provide the DLRX statement I need in the client to read C60 from the server? Do I need a publish c60 statement in the server?
As a side question - why is V0 the correct address for MHR1?
-
In order to do this you have to realize that the ECOM100 was designed for working with the memory of a DL-PLC, not a Do-more. So, to utilize the ECOM100 as a Modbus TCP master you have to use the DLRX/DLWX and put the correct type of Type & Offset (octal) in the MRX/MWX instruction to invoke the correct Modbus Function Code and Modbus memory addresses. This is outlined in this PDF document:
http://www.hosteng.com/FAQFiles/ECOM100%20Server%20Client%20Mapping%20%28Do-more%29.pdf (http://www.hosteng.com/FAQFiles/ECOM100%20Server%20Client%20Mapping%20%28Do-more%29.pdf)
Notice in that document that if you use a DLRX with an address of V0 in the client, then this will get translated by the ECOM100 as an FC03 (Read Holding Registers) with an offset of Holding Register 1. Thus when that telegram reaches the Ethernet port on your Do-more PLC that is a server, it will read MHR1 (Modbus Holding Register 1).
The client will only be able to access M-memory in your server Do-more. It cannot access C60. To access C60 you will have to use the PUBLISH in your server to move C60 to somewhere in M-memory and then correspondingly, use the map as shown in the above PDF document and enter the correct Type & Offset in your DLRX instruction in your client to get it.
Hope this helps!
-
This was one of ADC's most bizarre decisions (Using DL octal addressing for Modbus comm transactions)
Even if both client and master are in fact DL's, if you're using Modbus to connect them, why would you not want to use Modbus terminology and addressing to do so? And THEN if the server device is non-DL, it begins to feel truly ridiculous.
-
This was one of ADC's most bizarre decisions (Using DL octal addressing for Modbus comm transactions)
Even if both client and master are in fact DL's, if you're using Modbus to connect them, why would you not want to use Modbus terminology and addressing to do so? And THEN if the server device is non-DL, it begins to feel truly ridiculous.
From the perspective of the ECOM as a client, the answer is pretty simple: there is no CPU side Modbus support, Modbus is patched in through the original DCM's RX/WX DL to DL interface. As for other implementations throughout the line, I don't have any insight.
We did try to improve on that with Do-more, but I think our approach is somewhat unique in the market.
-
The client will only be able to access M-memory in your server Do-more. It cannot access C60. To access C60 you will have to use the PUBLISH in your server to move C60 to somewhere in M-memory and then correspondingly, use the map as shown in the above PDF document and enter the correct Type & Offset in your DLRX instruction in your client to get it.
Hope this helps!
Can't publish a "C", however I was able to use MOVER (C60 to MHRxx) and then in the client DLRX the V(MHRxx) to a V, and it worked. So with a bottle of aspirin and your help, I can make this work, Thanks.
The whole reason for this was to segregate some of my traffic by putting the ECOM100 in the DO-More Client rack, beginning to wonder if it's worth the effort, maybe I'll investigate a managed switch/s with vlan.
Thanks again
-
You should be able to PUBLISH C memory as a BYTE, WORD, or DWORD cast, but MOVER works fine too.
-
This was one of ADC's most bizarre decisions (Using DL octal addressing for Modbus comm transactions)
Even if both client and master are in fact DL's, if you're using Modbus to connect them, why would you not want to use Modbus terminology and addressing to do so? And THEN if the server device is non-DL, it begins to feel truly ridiculous.
This was never an ADC decision. I don't know that I can explain exactly why MODBUS uses Octal since it was done such a very, very long time ago. Let's put it this way, the oldest 405 CPU supports MODBUS. It was introduced around 1990.
I would say that why RX/WX instructions use Octal for MODBUS is a mystery lost to the annals of time. ;D
-
ADC/Koyo did address it in their implementation of the DirectLOGIC MRX/MWX instructions for the 260 and 06 CPUs built-in serial ports. The 06 even supports MRX/MWX in its DCM module. However, DirectSOFT's MRX/MWX instructions do not work for ECOMs in DL world.
Do-more's native Modbus MRX/MWX instructions work for built-in serial, built-in Ethernet, and SERIO modules, but not ECOM100 module. At least you can do the DL Hack of the Modbus Hack when using Modbus via ECOM100 in Do-more ;D.
-
You should be able to PUBLISH C memory as a BYTE, WORD, or DWORD cast, but MOVER works fine too.
See Publish C pic, this is what I get when I try publish C to anything
Publish to MC pic, this is what I get if I try to publish anything to a MC
Probably I'm doing something wrong
-
Try 'C0:W' to grab 16 bits at a time as a word. The 'Modbus' registers only include the 'Input' and 'Holding' register, not the discrete - single bit - registers.
-
Try 'C0:W' to grab 16 bits at a time as a word. The 'Modbus' registers only include the 'Input' and 'Holding' register, not the discrete - single bit - registers.
That works, thanks.
-
This was never an ADC decision. I don't know that I can explain exactly why MODBUS uses Octal since it was done such a very, very long time ago. Let's put it this way, the oldest 405 CPU supports MODBUS. It was introduced around 1990.
I would say that why RX/WX instructions use Octal for MODBUS is a mystery lost to the annals of time. ;D
And not just octal, but you have to include the "V" as well! Strange. I know what you mean; I'm so much happier with today's hardware (from all PLC manufacturers) than 1985 era stuff. Life is good now!
Thank you for the background! :)
-
Do-more's native Modbus MRX/MWX instructions work for built-in serial, built-in Ethernet, and SERIO modules, but not ECOM100 module. At least you can do the DL Hack of the Modbus Hack when using Modbus via ECOM100 in Do-more ;D.
I've only used the native port so far as Modbus client on Do-More, and I MUCH prefer the way it is now. Much cleaner, much more comfortable for someone familiar with Modbus. Do-More rocks!
-
ADC/Koyo did address it in their implementation of the DirectLOGIC MRX/MWX instructions for the 260 and 06 CPUs built-in serial ports. The 06 even supports MRX/MWX in its DCM module. However, DirectSOFT's MRX/MWX instructions do not work for ECOMs in DL world.
Do-more's native Modbus MRX/MWX instructions work for built-in serial, built-in Ethernet, and SERIO modules, but not ECOM100 module. At least you can do the DL Hack of the Modbus Hack when using Modbus via ECOM100 in Do-more ;D.
Can I get this on the wish list, Do-more's native Modbus MRX/MWX instructions to work with ECOM100
-
The client will only be able to access M-memory in your server Do-more. It cannot access C60. To access C60 you will have to use the PUBLISH in your server to move C60 to somewhere in M-memory and then correspondingly, use the map as shown in the above PDF document and enter the correct Type & Offset in your DLRX instruction in your client to get it.
Hope this helps!
Can't publish a "C", however I was able to use MOVER (C60 to MHRxx) and then in the client DLRX the V(MHRxx) to a V, and it worked. So with a bottle of aspirin and your help, I can make this work, Thanks.
The whole reason for this was to segregate some of my traffic by putting the ECOM100 in the DO-More Client rack, beginning to wonder if it's worth the effort, maybe I'll investigate a managed switch/s with vlan.
Thanks again
I've tried the managed switch route. I was unable to get it to work. A switch manufacturer thought that setting up a 1-1 NAT between the Do-More IP and the external network would work. But it didn't. I bought an expensive industrial switch but even the switch manufacturer couldn't get it to work. The only way it would have worked was if there was only 1 Do-More on the network, but then you wouldn't need the managed switch anyway (or an ECOM card).
The only thing I've been able to get to work with multiple Do-More CPUs on the same network is to use the ECOM100 card for network access and the Do-More port for the isolated expansion network. Then you have the issues with the ECOM100 limitations, but it's the only option that I've found that works.
-
When y'all are talking about segregating traffic and certain system configurations not working, can you be more specific and what doesn't work? There are a few things we use broadcasts for, but for the most part we avoid them, and as such I would expect a normal switch to keep things pretty clean. If you are using the onboard port for I/O, and wanting to keep HMI traffic off that port, then yeah, the ECOM is the only way around that (at the present time ;)).
-
I know what you mean; I'm so much happier with today's hardware (from all PLC manufacturers) than 1985 era stuff. Life is good now!
I just last week ran into a failed SLC-500 DC output card that had OCTAL stenciled on the front and the terminal layout card in the door was octal. It was in a remote rack on a VMEbus PLC5. That's all that was different and a standard part number worked just fine.
-
Yup. SLC modules came with both octal and decimal door labels (and clear adhesive labels for the module status LEDs) so you'd have whichever you needed depending on whether the processor was a SLC or a PLC. IIRC, PLC modules did too, in case you used them as SLC RIO. I just slapped an old SLC module with an octal door label into a SLC system a couple months ago, and the program didn't mind a bit! ;)
-
I wouldn't recommend that with the BCD model. ;D
-
When y'all are talking about segregating traffic and certain system configurations not working, can you be more specific and what doesn't work? There are a few things we use broadcasts for, but for the most part we avoid them, and as such I would expect a normal switch to keep things pretty clean. If you are using the onboard port for I/O, and wanting to keep HMI traffic off that port, then yeah, the ECOM is the only way around that (at the present time ;)).
Yes, that's what I meant by isolated expansion networks. The network for the expansion bases is physically separated from the HMI/programming network. So each PLC is connected to only it's own expansion bases and through a different connection (the ECOM100) to the HMI network. That way each expansion base is visible to only it's master CPU. No other Do-More can see it.