Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: mhw on March 12, 2015, 09:49:07 AM
-
I am converting an old DL project to DoMore. Memory needs to be available to KEP so I am limited to DLV for variables. I am unable to cast DLV's as a real number when used in a relational contact. Is this a bug? What are my options? When will we see a KEP driver for DoMore?
-
In Do-more, when you cast to a LARGER size, the ID must ALIGN on that size. Hence, to cast a 16 bit DLV to a 32 bit REAL, it must align on DWORD, meaning the ID must be EVEN (DLV1400:R or DLV1402:R, but NOT DLV1401:R.
This is the nature of the microprocessor.
Hence, you will have to tweak your memory map of your DLV, aligning any REAL or DWORD sized integers on EVEN DLV IDs.
-
That was it. How could you see that from there?
-
How could you see that from there?
We have a full duplex display driver as part of Do-more. We can write to the display AND read your screen, so we know what you are doing/trying. It's just a matter of adding extra wires to your VGA cable, just like full duplex RS-232. ;)
-
Not sure what version of KEP you are using. I am using KEPServerEX, which has a MODBUS/TCP driver. So I use Publish and Subscribe to convert Do-More Real values to Modbus Floats. See example pics. Hope this helps.
-
That was it. How could you see that from there?
Don't let Mark creep you out with the "NSA is watching you stuff". Although we can reverse your monitor and see in your office, we choose not to do so, and instead rely on our clairvoyance. Actually...there's pretty much only one thing that keeps it from working.
You can also use PUBLISH and SUBSCRIBE to move to and from unaligned public memory to aligned memory.
-
I'll poke the ADC KepDirect Product Manager and see what is up with development on the Do-more front. He is out of the office today so it might be next week before I have an answer. If I forget to answer back, you know how to reach me Mike.
-
I'll poke the ADC KepDirect Product Manager and see what is up with development on the Do-more front.
Thanks Richard. It will be too late for this project unless it is coming out tomorrow.
Don't let Mark creep you out with the "NSA is watching you stuff".
I'm not worried...I wrapped my head in aluminum foil so he can't get to me.
Unrelated question.
In this project I will be doing DLRX's and DLRW's to 3 different 06's that are being used as dumb IO. Should I create a separate device for each? Or maybe my question should be, what is the fastest way with the least network overhead to exchange data with them?
-
Definitely make a separate device for each one.
-
Definitely make a separate device for each one.
Yes...although since DLRX/WX user UDP, the difference is not nearly as dramatic as TCP.
-
mhw, I sometimes let franji1 borrow my tech service palantir. As anyone who's ever worked in technical service will tell you, it is a necessary device for those occasional customers who send you an email and say NOTHING but, "Hey, my stuff is broke. What's wrong with it? Thanks!"
-
Yes...although since DLRX/WX user UDP
So when I configure a new device I should create a UDP connection?
If yes, then is the port the same thing as module ID?
Is it important to setup the peer to peer in the ECOM's?
-
So when I configure a new device I should create a UDP connection?
No. UDP devices are used only for custom protocols. The issue being discussed was related to connection oriented clients where to talk to multiple things with the same device requires a connect/disconnect cycle for every comm. For unconnected client (like DLRX/WX) there is no performance penalty to use a single device to talk to multiple things.
-
Is it important to setup the peer to peer in the ECOM's?
Yes, if you are using an ECOM/ECOM100 in the Do-more (instead of the onboard Ethernet port) as the client (master). In this case, then in the DLRX/DLWX instruction you want the "Slave ID" parameter to match the "RX/WX Device Number" in your Peer-to-peer table entry.
-
I am confused..
This was my original question:
I will be doing DLRX's and DLRW's to 3 different 06's that are being used as dumb IO. Should I create a separate device for each? Or maybe my question should be, what is the fastest way with the least network overhead to exchange data with them?
And my responses were:
Posted by: plcnut
Insert Quote
Definitely make a separate device for each one.
and
Posted by: BobO
Insert Quote
Quote from: plcnut on March 13, 2015, 10:05:57 am
Definitely make a separate device for each one.
Yes...although since DLRX/WX user UDP, the difference is not nearly as dramatic as TCP.
So from those responses I assume that I need to make a new UDP device, but..
Posted by: BobO
Insert Quote
Quote from: mhw on April 09, 2015, 10:33:42 am
So when I configure a new device I should create a UDP connection?
No. UDP devices are used only for custom protocols. The issue being discussed was related to connection oriented clients where to talk to multiple things with the same device requires a connect/disconnect cycle for every comm. For unconnected client (like DLRX/WX) there is no performance penalty to use a single device to talk to multiple things.
So back to my question worded in a different way. What is the fastest way with the least network overhead to exchange data between multiple H0-ECOM100s and the onboard Ethernet port of a DoMore?
-
MODBUS TCP with a unique MODBUS TCP Client created for each slave.
Although using DLRX/DLWX is probably going to be nearly as fast. And since this route is UDP based with this route you do not have to create new devices for each slave.
And BobO answered it better than I did. :) No shocker there.
-
Multiple conversations get interlaced and confusion reigns.
There are (for now) two basic ways to move data between these devices: MRX/MWX (Modbus/TCP) and DLRX/DLWX(DL peer to peer).
Since Modbus/TCP is built on TCP...which is connection based...if you aim to talk to more than one thing, you should create a Modbus/TCP Client for every device you want to talk to. It isn't required, but it will greatly enhance the performance.
DL peer to peer, on the other hand, is built on UDP...which is unconnected...and if you want to talk to more than one thing, there is no significant performance penalty to do so using only one connection. Which is a very good thing...because it isn't possible to create additional clients for DLRX/DLWX.
The UDP Connection device that you referenced has nothing to do with DLRX/DLWX. Those devices are for creating custom protocols.
So the simple answer is to use DLRX/DLWX on the one and only built-in client. Unless you just really wanna use Modbus/TCP, then use MRX/MWX, and create a Modbus/TCP Client for each target device that you wish to talk to.
-
MODBUS TCP with a unique MODBUS TCP Client created for each slave.
Although using DLRX/DLWX is probably going to be nearly as fast. And I am pretty sure with this route you do not have to create new devices for each slave.
Modbus/TCP allows you to overlap comms to multiple devices...which could be faster...but with the additional overhead of processing multiple TCP sockets. DL peer to peer must process each request one at a time...which might be slower...but only requires processing one UDP socket. I could build a pretty good case for either one to win in certain circumstances. The only absolute is that DLRX/DLWX is easier.
I don't actually think there is a right or wrong answer, hence the confusion.
-
And BobO answered it better than I did. :) No shocker there.
I cheat...I have the teacher's addition of the textbook. ;)
-
Thanks for the clarification!