Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: CReese on June 26, 2013, 11:32:58 AM
-
Ok I've now skimmed the entire 16 pages to make sure my questions weren't already answered. Please direct me elsewhere if they have.
1. Do the DLRX and DLWX commands work from DoMore to DL260 CPU memory locations? The FAQ elsewhere seems to imply that they do, but it's ambiguous enough I'd like clarification.
2. Is the only communication possible between DoMore and P3000 PACs over MODBUS?
2. Is it possible to parameterize a MODBUS TCP/IP read or write parameter? If #2 is true, to make the scenario workable I'd need to loop over modbus reads with addresses (and ideally IPs) stored in arrays. From what I can tell, this is not possible currently.
Best regards,
C
-
1. Do the DLRX and DLWX commands work from DoMore to DL260 CPU memory locations? The FAQ elsewhere seems to imply that they do, but it's ambiguous enough I'd like clarification.
Yes. When mastering from Do-more, the target/source address in the Do-more CPU can be any Do-more address. The source/target in the DL260 is any valid DL260 address. When Do-more is the slave, it's a bit different.
2. Is the only communication possible between DoMore and P3000 PACs over MODBUS?
Don't really know. Do-more speaks DL and Modbus, and it is easily possible to create virtually any protocol programmatically with our custom protocol instructions. I have very little knowledge of what P3K does, but I think they use Modbus pretty heavily.
2. Is it possible to parameterize a MODBUS TCP/IP read or write parameter? If #2 is true, to make the scenario workable I'd need to loop over modbus reads with addresses (and ideally IPs) stored in arrays. From what I can tell, this is not possible currently.
It is not. It would be possible with DL due to the fact that all they are doing is pushing parameters to a stack before calling the actual comm function. We talked about making them variables in Do-more, but many customers already find the instructions confusing, and in the effort to simplify, we chose not to. After your request on ADC's forum we added a case to look into it, but I don't guess that will help you now.
Between Do-more controllers, it would be pretty easy to create a custom protocol to do this, and if you were really up to it, you could even create your own Modbus master. But this is pretty advanced, and unless you have experience writing comm protocols I wouldn't advise it.
-
2. Is it possible to parameterize a MODBUS TCP/IP read or write parameter? If #2 is true, to make the scenario workable I'd need to loop over modbus reads with addresses (and ideally IPs) stored in arrays. From what I can tell, this is not possible currently.
CReese,
Would creating multiple connections, and placing them in a series of Stages be unreasonable?
You could use the JMPI (jump to indexed stage) command to loop through the connections.
How many connections, and what kind of speed are we talking about?
-
Well, most of this can be solved for the most part if I can parameterize DL read/write operations. Please tell me this is possible.
What I have is the following case:
I have several systems where I have 20-40 IOs, each with a PLC handling some very basic operational logic. I then have a remote PLC that reads that data, performs some higher-level alarm logic, processes HMI input (ack, mute, etc.), and keeps track of what's on fire and what should make noise.
This system is reproduced a few times per year, so I want to reproduce code and selectively change addresses and disable IO code where necessary. I don't want to hunt through hundreds of pages of IO code to change all of the memory locations and delete code never to see it again. In the supervisory PLC, I want modular code that operates on an array of values to read and handle all of the alarm conditions and output to an array. A chunk of analog alarm code, for example, takes a high SP, low SP, alarm on/off delays, reads a control variable from a remote PLC and carries out some logic to produce an alarm (or not).
If I can parameterize the network read commands, all I need is an array each for PLC location and the address to read. Without, I will have either a network read block for each of the 20-40 IOs x N systems, or I will have to read huge blocks and parse them out using an array of memory locations. Either is obviously undesirable.
As I mentioned on the other forum, at least with DS5 I can load a parameterized modbus address in the stack and increment it.
-
As far as confusing folks goes, I really do like the new functions, and am happy you wrapped them up as you did. If only the address fields accepted variables, those that found it confusing could just leave it. I do really like the ability to use array functions and index them natively. It's as if you put all the pieces together to make my life easier, but without this final piece.
-
I don't know much about the guts of DL native protocols, but Modbus is dead easy (aside from writing FF00 to set a single bit as I learned the hard way a couple weeks ago ;D). With TCP you don't even have to calculate checksums anymore. It sounds like the project is of such a scope, and the payoff sufficient, that it would justify implementing Modbus as a custom protocol, and I would encourage you to at least take a look at doing so.
-
Can somebody point me toward info on these custom protocols you speak of?
-
Can somebody point me toward info on these custom protocols you speak of?
Look at OPENTCP, STREAMOUT, and STREAMIN instructions, possibly used in conjunction with stage programming.
For ASCII protocols, there's also a large variety of string construction, parsing, and comparison instructions (which you won't need for Modbus).
As far as how to frame a Modbus request, there's tons of docs on that all over the web, including http://modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf (http://modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf) from the horse's mouth.
-
Can somebody point me toward info on these custom protocols you speak of?
Do-more provides a nice suite of functions for implementing custom protocols over TCP/IP and UDP/IP, as well as over serial. For TCP, you create a TCP Client connection in the Device Manager, open a connection to the target server with OPENTCP, use one or more STREAMIN/STREAMOUT instructions to do the transaction, various STRxxx functions to manage the payload, and CLOSE to close the connection when done. I would definitely use a dedicated program block, and use Stages to control the flow. There are some examples of custom protocols in the Do-more Examples section...a DirectNet server over serial and an HTTP client.
Please do not contact ADC on this. They really cannot help and it is beyond the scope of their support. Ask here and we'll do our best to keep you moving. Several of the posters here have developed custom protocols in Do-more.
-
Thanks for the info.
I'd like to throw a few things out there:
1. It seems counterintuitive that a feature would be eliminated in an upgrade. Even if you hide it, which I understand, it should still be available.
2. I find it hard to believe that others don't have 100+ network reads they want to do and find 100 separate, hardcoded network blocks an untenable, inflexible, and unscalable proposition.
3. I will not commission the first of several systems for several months. The ability to do what I've proposed in some capacity or another, whether it's a custom protocol or with an updated MODBUS TCP/IP or DLRX/DLWX blocks (probably better for the rest of your customers), is make or break. As blasphemous as this sounds, I would stay with my DL260 and pay $300 more per base to have the capability I am describing, despite the obviously inferior hardware in every other respect. If I add up my time coding, maintaining, and rewriting, I have no doubt it would still pay off. Or I may look elsewhere.
Anyhow, I'm looking down dozens of PLCs, IOs, bases and associated hardware per system for a couple systems a year. Who do send the beer to make this happen?
C
-
1. It seems counterintuitive that a feature would be eliminated in an upgrade. Even if you hide it, which I understand, it should still be available.
I think you are misrepresenting the 'feature'. There are dozens of things you can do in DL that we cannot do in Do-more due to the stack structure. The best thing I can compare it to is all of the junk you can do in assembly that you cannot do in C++. I would hardly consider assembly better because it can access registers. While you see the ability of DL to stuff whatever random value onto the stack and attempt to use it in a comm protocol, I see it as a potential point of confusion. In Do-more, there are far more possible wrong answers than in DL...think: floating point Modbus addresses. We chose to implement the instruction in a way that afforded us the best chance of preventing trouble, but apparently that preventing it from doing what you need it to do. I am sorry we didn't anticipate the need.
2. I find it hard to believe that others don't have 100+ network reads they want to do and find 100 separate, hardcoded network blocks an untenable, inflexible, and unscalable proposition.
I don't know what others do, but this is the first request for it.
3. I will not commission the first of several systems for several months. The ability to do what I've proposed in some capacity or another, whether it's a custom protocol or with an updated MODBUS TCP/IP or DLRX/DLWX blocks (probably better for the rest of your customers), is make or break. As blasphemous as this sounds, I would stay with my DL260 and pay $300 more per base to have the capability I am describing, despite the obviously inferior hardware in every other respect. If I add up my time coding, maintaining, and rewriting, I have no doubt it would still pay off. Or I may look elsewhere.
I'm not entirely sure how to respond to that. You are basically threatening to take your business elsewhere if I don't give you what you want. While I am inclined to crawl over glass to give folks what they want if they ask nicely, you have been pretty heavy handed on this since you brought the issue up. I can make this happen...probably by next week...but I respond better when people ask nicely. Criticizing a product that is far more capable than what you are using, but happens to lack one thing you need, isn't the most friendly. Sorry if that sounds un-diplomatic, but that's how I hear it. I understand your frustration, and the truth is that we have already started work on this...and will try to sneak it into 1.1. But dude...I heard about this like...yesterday. Gimme a sec, ok. ;)
-
I'm sorry it came across that way. I'm just trying to state my position and my needs, design-wise. I will do whatever I need to do to accomplish my goals, and have no personal stake in what it takes to get there. If hardware won't do what I want, I'll find some that will. It's certainly not personal.
I'd be happy to write a piece of code to build in the capability I am describing, but it doesn't sound easy. I've plenty of experience hacking stuff together to make it work.
I am clearly surprised and frustrated that what seem to be obvious features are not built in from the start. I see complaints all over the place (not just here) about hardware requirements that I think are absurd, but nobody wanting to write compact, modular, reusable code. I can't decide if this is application-specific, or just complacency with a few obvious deficiencies in typical ladder-logic programming, one of which I'm pointing out here: modularity.
I was really excited about many features in the new DoMore and P3000 controllers, and remain impressed with the price and feature improvements of the DoMore series. This is one feature that just isn't quite there yet. If it wasn't clear, I WANT to use the hardware, but I just can't.
Make sense?
-
@CReese, I see several relatively simple paths to make this happen:
- Do a custom protocol. As I said before, the scope of the project and the payoff make the moderate amount of effort required easily worthwhile.
- Use a 260 as the central PLC. Not ideal, but if all it's doing is collecting and alarming on data, it certainly shouldn't be untenable (plus allows one programming software for every PLC in the system).
- Use DL PLC's as planned for all the remotes, but use an HMI or PC running HMI software as the alarm aggregator. Something that will allow programmable configuration for the remotes as desired. Also not difficult. In fact, if I were doing this app, it would have occurred to me to use something like this rather than a supervisory PLC in the first place, unless that PLC is doing some of the actual machine control.
I definitely understand your reaction to capability disappearing in what's otherwise an upgrade, but given the availability of reasonable alternatives it doesn't seem like a problem.
@BobO: Thinking about this issue gave me kind of a revolutionary/radical idea (Oh no, here it comes!). My PC-based HMI has a lot of scripting capability. It also includes two functions, execute() and evaluate(), that allow you to symbolically build a string from an expression, ala STRPRINT, then execute the resulting string as a script statement.
How about a "MNEM" instruction that would do the equivalent for ladder? Build a monic string from an expression and then execute it as if it were hard coded? Or two steps: STRPRINT to an string, plus an EXECUTE box that takes a string as it's argument?
That would take care of this issue for every instruction there is, while still maintaining the simplicity of the basic literal version of the instruction.
-
How about a "MNEM" instruction that would do the equivalent for ladder? Build a monic string from an expression and then execute it as if it were hard coded? Or two steps: STRPRINT to an string, plus an EXECUTE box that takes a string as it's argument?
That would take care of this issue for every instruction there is, while still maintaining the simplicity of the basic literal version of the instruction.
It is one thing to add a compiler to a PC...we have one of those called Do-more Designer. ;) It is a far, far different thing to add such to the PLC itself.
-
@JReese, I see several relatively simple paths to make this happen:
- Do a custom protocol. As I said before, the scope of the project and the payoff make the moderate amount of effort required easily worthwhile.
I think this is probably most likely
- Use a 260 as the central PLC. Not ideal, but if all it's doing is collecting and alarming on data, it certainly shouldn't be untenable (plus allows one programming software for every PLC in the system).
One of the reasons we don't currently do this is that DS doesn't allow breaking up the code into manageable chunks. So what we have are one or two dozen 260s that manage all of their own logic, and then we aggregate as necessary and read from a dozen of them with a half dozen screens. It is a mess, both from a maintenance standpoint (which is more often than not remote - the things are on the water), and also from a code reuse and feature add/remove perspective. Having everything in one place without a single 400 page-long program is a must. I'd also consider all of this in one place relatively heavy lifting .. and I'd need enough memory space to handle it all, which is not possible on a single 260 : too many bits, batman! If I could easily log (hence consideration of the P3000) and access from the intertubes, that would be ideal.
- Use DL PLC's as planned for all the remotes, but use an HMI or PC running HMI software as the alarm aggregator. Something that will allow programmable configuration for the remotes as desired. Also not difficult. In fact, if I were doing this app, it would have occurred to me to use something like this rather than a supervisory PLC in the first place, unless that PLC is doing some of the actual machine control.
This is something that we've considered. We've also done a lot of logic and all of our alarms in screens before, but our screens have limitations on how many devices to speak to, and then you have to designate one the master and the rest speak to it. That is also a mess. It also means that if I have remote logging/monitoring, it has to run through the screens. I am pretty solidly of the opinion that the screens should be stupid and just read from the PLCs. Screen dies? Throw it away, install the HMI program on a new one, no muss no fuss, regardless of which screen it is.
I did not mention it, but reliability is a huge concern. These are deployed on boats for years, and we support for many years after deployment. PC control is not an option, even for alarms. Alarm notification is mission-critical stuff for fires and whatnot.
[/list]
I definitely understand your reaction to capability disappearing in what's otherwise an upgrade, but given the availability of reasonable alternatives it doesn't seem like a problem.
Yeah, I don't know the details of the PLC program layer, so I'm obviously missing something there. I am certainly happy to be done with BCD/Hex and the math jumping jacks I'm currently doing to program in DS5. It is not fun, but I'm happy to do it to realize where improvements can be made.
Another point I'll make on "threatening" to buy somebody else's hardware. Most customers won't tell you what made them buy or not buy your product, or even that they bought something else. In my personal business, I spend a lot of time trying to gather this information. If one of my customers told me he needed a feature to make a purchase an option, in what timeframe, what type of sales this meant, or that he/she hadn't bought my software/hardware because of it, I would gratefully take that information into account. I have always been happy to get this sort of feedback and tell them whether or not I was able to help them out and why. I was simply trying to offer meaningful context for my request.
Best,
C
-
It is one thing to add a compiler to a PC...we have one of those called Do-more Designer. ;) It is a far, far different thing to add such to the PLC itself.
Like CReese, I haven't the least clue about building PLC firmware, but since we no longer have macros (I-Boxes), aren't the monics essentially the equivalent of assembly code for the processor? Or do individual instructions still translate to many native CPU ops?
IOW, I believe you, but I don't have a complete grasp of the issues involved. Expound please, if you think it would help.
-
@CReese
My issue is simply tone, sir. I get that you are frustrated, that was clear from your first posting. I have already said we are adding variable support (MRX/MWX only...there are issues with DLRX/DLWX) and it will be in the imminent 1.1 release, which will likely be released next week. I don't know what else I can do to make it right.
@Controls Guy
Not really, no. Boxes like MRX are high level function blocks written in C++. The 'code' that DmD writes is just an opcode and 11 parameters that the associated function block reads and interprets. The function block has no provision for a variable target address.
One major reason we eliminated variables for target addresses is because as part of compiling for the controller, DmD does some pre-processing of the address. For Modbus, that is simply to subtract 1 from the register to convert from user address to the actual on-the-wire value. Very minor. For DLRX/DLWX we translate all of the possible data types to the appropriate CCM code...removing that translation from the controller made it more efficient, but eliminated the possibility of variables. It is simple for Modbus so we are adding it.
-
I haven't the least clue about building PLC firmware, but since we no longer have macros (I-Boxes), aren't the monics essentially the equivalent of assembly code for the processor? Or do individual instructions still translate to many native CPU ops?
IOW, I believe you, but I don't have a complete grasp of the issues involved. Expound please, if you think it would help.
Except for the Numbered NOP, DirectSOFT5 IBoxes are ALL LIPSTICK (inside joke).
-
LOLZ, mauve or puce?
-
Not really, no. Boxes like MRX are high level function blocks written in C++.
Yeah, that makes sense. Should have been obvious, actually, that you couldn't get a single CPU op to do an entire Modbus read.
-
LOLZ, mauve or puce?
24k gold ;D.
-
The stuff it encapsulated was such a boar, so....yeah!
-
The stuff it encapsulated was such a boar, so....yeah!
LOL2
-
I'll be here all week! Be sure to try the veal! [rimshot]
-
Ok...done and lightly tested, and it works great. Currently allows for any valid integer variable or array reference in MRX and MWX boxes. As was previously mentioned, DmD does some protocol translation for DLRX and DLWX, so we aren't doing them at this point. Given that most of our stuff speaks Modbus as well as DL, that shouldn't be too limiting.
Prior to this change, we were likely going to release 1.1 within a few days, but I think we need to do another release candidate and kick the tires a bit more. Barring critical problems in general, it will likely be late next week for final release.
-
Very cool. What is the new feature/bug fix list for v1.1?
-
There's a bunch. I'll email you.
-
...forgot this in previous post. In addition to variables, it also works with decimal symbolic constants.
-
Wait, what? I can has symbolic constants? Why was I not informed??
UPDATE: Went and looked and there it is! VERY VERY important feature. This should be in Doug Bell's training if it's not there already (I haven't got all the way through that yet either)
I think I'd like to see a tabbed interface for the doc editor and have the constants on their own tab.
Plus, allow me to right click on symbolic constants and Add New, like a lot of other list headings.
(Not suggesting new features for v1.1, just to put on the list)
-
It was added late and on the cheap. UI is expensive and time consuming, so we added it the way you see. But yes, you can has symbolic constants...and cheeseburgerz if you so desire.
-
It is one thing to add a compiler to a PC...we have one of those called Do-more Designer. ;) It is a far, far different thing to add such to the PLC itself.
Is this also an issue for paramaterizable function calls and expressions everywhere a variable will go?
We originally thought about the MOVE(single reg)/ASSIGN as just shorthand for LD/OUTW...then realized that when we make every qualified input parm into an expression (coming later), that functionally, MATH == ASSIGN/MOVE(single reg). It was at that point that we started thinking of MOVE as a multi-register table function...COPY if you will...and we're not really sure what to do with MATH/ASSIGN/MOVE(single reg). So we did nothing...which I find to be the best choice given no better alternative.
-
Anything that can take a variable has the capacity to take an expression, and we have tried to make virtually everything take variables. So the only limitation will be us deciding where to allow expressions. Callable functions will work fine for the same reason expressions work.
This one particular case we chose to use constants only to simplify entry, to allow us to bounds check, and to offload some of the work from the CPU to DmD by preprocessing. Truthfully, it made great sense for the DL instructions, but not as much for Modbus. We designed the DL instructions first though, then modified for Modbus, and once designed we try to stick to repeatable patterns for the same reasons you guys do. It just never crossed our mind that we were doing a Very Bad Thing. It's fixed now.
-
Ok...done and lightly tested, and it works great. Currently allows for any valid integer variable or array reference in MRX and MWX boxes. As was previously mentioned, DmD does some protocol translation for DLRX and DLWX, so we aren't doing them at this point. Given that most of our stuff speaks Modbus as well as DL, that shouldn't be too limiting.
Prior to this change, we were likely going to release 1.1 within a few days, but I think we need to do another release candidate and kick the tires a bit more. Barring critical problems in general, it will likely be late next week for final release.
Super. Thanks for your timely help.
IP isn't one of the parameters, is it?
-
So back to the application question: given the capability of DoMore PLCs, an attached PC, and network access, how would you PLC gurus set up logging and periodic network upload?
What is a good PC/PLC interface that will play nice with DoMores and make configuration a snap?
While I'm asking, are there any linux apps or drivers for DoMores?
Ideally we could see tag names rather than having to do straight MODBUS and enter a map.
-
So back to the application question: given the capability of DoMore PLCs, an attached PC, and network access, how would you PLC gurus set up logging and periodic network upload?
What is a good PC/PLC interface that will play nice with DoMores and make configuration a snap?
While I'm asking, are there any linux apps or drivers for DoMores?
Ideally we could see tag names rather than having to do straight MODBUS and enter a map.
I would definitely use TCP. If the Do-more is initiating the data (e.g. Do-more is logging events), use OPENTCP to your PC's IP Address on an unused TCP port, then use one or more STREAMOUTs, followed by CLOSE to terminate the TCP connection.
If the Do-more is passive and waiting for some recipe data from some PC app, use the TCPLISTEN instruction on a specific port, then use 1 or more STREAMINs, waiting for the other side to close the TCP connection (by monitoring a bit in the TCP Server structure in your Do-more).
UDP can also be used, if you want more of a serial type interface (uses PACKETIN/PACKETOUT), or use serial ;D (built-in or H2-SERIO module, which uses STREAMIN/STREAMOUT).
-
IP isn't one of the parameters, is it?
It wasn't, but that was one we already wanted to do, so we are going to go ahead and do it.
-
So back to the application question: given the capability of DoMore PLCs, an attached PC, and network access, how would you PLC gurus set up logging and periodic network upload?
What is a good PC/PLC interface that will play nice with DoMores and make configuration a snap?
While I'm asking, are there any linux apps or drivers for DoMores?
Ideally we could see tag names rather than having to do straight MODBUS and enter a map.
If you really want to learn, and make a powerful configuration tool, then see this example: http://forum.hosteng.com/index.php/topic,1117.0.html
This server has the ability to display and/or modify any memory area in the Do-more via html and JavaScript coding and GET (or otherwise delimited) variables. I have many more examples I have used for myself, but each part is so custom that you really can't just throw together an example that shows all of the possible uses. The possibilities are close to endless. If you attempt to use this sample and run into trouble, I will try to help if time allows.
-
So back to the application question: given the capability of DoMore PLCs, an attached PC, and network access, how would you PLC gurus set up logging and periodic network upload?
What is a good PC/PLC interface that will play nice with DoMores and make configuration a snap?
While I'm asking, are there any linux apps or drivers for DoMores?
Ideally we could see tag names rather than having to do straight MODBUS and enter a map.
If you really want to learn, and make a powerful configuration tool, then see this example: http://forum.hosteng.com/index.php/topic,1117.0.html
This server has the ability to display and/or modify any memory area in the Do-more via html and JavaScript coding and GET (or otherwise delimited) variables. I have many more examples I have used for myself, but each part is so custom that you really can't just throw together an example that shows all of the possible uses. The possibilities are close to endless. If you attempt to use this sample and run into trouble, I will try to help if time allows.
When I heard js, my interest was piqued. Have been doing a lot of sql and js in my other business. It would be excellent if I could negotiate an sql-type dump of all memory, or simply direct-reading all memory into an sql database on the PC periodically. I could then use js on the PC side to parse the sql into something pretty for the user, or just ssh in to retrieve the dump.
On the above, however, I'd prefer to run a 'nix box for security and familiarity sake. All I'd really need is a "read all memory" command that I could parse into a database. I suppose there have to be all sorts of MODBUS TCP/IP drivers out there for linux.
-
and here we go ... http://www.freemodbus.org/
-
IP isn't one of the parameters, is it?
It wasn't, but that was one we already wanted to do, so we are going to go ahead and do it.
Now we're cooking with fire.
I promise code excerpts if there is an easy way to do so once I get everything nailed down.
-
The only problem with MODBUS (also part of what makes it good...) is that it is restricted to only being able to read what you put into the Do-more MODBUS registers(correct me if I misunderstand on this one). The beauty of the custom protocol/webserver, is that you STREAMOUT any and every memory area you like, and in the order you like... to whatever you like.
It is seriously very cool!
BTW: Using a php script and the String/STREAM instructions, I am able to dynamically update an entire MySQL database from my Do-more at the press of a button... on a webpage... from anywhere...
-
The only problem with MODBUS (also part of what makes it good...) is that it is restricted to only being able to read what you put into the Do-more MODBUS registers(correct me if I misunderstand on this one). The beauty of the custom protocol/webserver, is that you STREAMOUT any and every memory area you like, and in the order you like... to whatever you like.
It is seriously very cool!
BTW: Using a php script and the String/STREAM instructions, I am able to dynamically update an entire MySQL database from my Do-more at the press of a button... on a webpage... from anywhere...
Ok, so unlike the DL series, you can't just attempt a read + offset from particular registers. You have to have it mapped. I had not yet wrapped my head around the implications of that. Interesting. Much more powerful.
That's neat and interesting. I'm not sure I want to insert that functionality into the PLC. My instinct would be to port some other code I've used to have js/ajax to pass to/from python scripts that run sqlite or mysql queries on the database that lives on the server. This way any barfing I do server-side is isolated from the PLC. I stay as far away from php as possible. phpmyadmin and phpliteadmin are nice tools, but I don't touch the stuff aside from that. No need to these days.
-
Ok, so unlike the DL series, you can't just attempt a read + offset from particular registers. You have to have it mapped. I had not yet wrapped my head around the implications of that. Interesting. Much more powerful.
Not sure I understand the comment, which I assume refers to plcnut's server sample. There are additional levels of indirection available in Do-more that were not in DL, but I don't think we removed any. Can you elaborate?
-
Maybe I'm missing something, but in the DL series, if you wanted to read a Vmem location, you found the address, calculated the offset from the beginning of the address block, converted number formats, and send a modbus read. There is no mapping required.
What I understood from the previous comment (and what makes sense, give the editable memory blocks and references), is that you have to explicitly map address locations to exposed modbus addresses. Is this correct?
-
Not sure I understand the comment, which I assume refers to plcnut's server sample. There are additional levels of indirection available in Do-more that were not in DL, but I don't think we removed any. Can you elaborate?
If I create a data block called "MyBlock", I cannot use a MODBUS read from another PLC(or PC) to reference that block. I would have to use MOVE(R)/MEMCOPY to move MyBlock to another memory area accessible by MODBUS.
Correct? (I have never gotten deep at all into MODBUS)
-
Maybe I'm missing something, but in the DL series, if you wanted to read a Vmem location, you found the address, calculated the offset from the beginning of the address block, converted number formats, and send a modbus read. There is no mapping required.
What I understood from the previous comment (and what makes sense, give the editable memory blocks and references), is that you have to explicitly map address locations to exposed modbus addresses. Is this correct?
In DL, Modbus was mapped through the entire internal memory, and yes, you had to do some math to get what you wanted, but you could directly access everything in the controller.
In Do-more, any Modbus server/slave references the Modbus Mxx memory types, and only them. You can directly reference Mxx blocks from your program, so copying is only required if you don't want to use the Mxx locations directly in your program. If you do choose to copy, look at the PUBLISH and SUBSCRIBE instructions. They are designed to do exactly that, while performing any data conversions that might be required.
So why did we do it that way? Several reasons:
1) Modbus can't realistically map to everything in a Do-more controller, and since Do-more is dynamic, the mapping DL style would be a mess.
2) Modbus is not secure, so giving it direct access to everything in your controller is unwise (trust me, we've dealt with the Department of Homeland Security on this issue).
3) If I want to access Modbus Holding Register 187, it doesn't get any easier than MHR187. Whereas in DL, MHR187 is likely at V3721 or some other random octal numbered location.
-
If I create a data block called "MyBlock", I cannot use a MODBUS read from another PLC(or PC) to reference that block. I would have to use MOVE(R)/MEMCOPY to move MyBlock to another memory area accessible by MODBUS.
Correct? (I have never gotten deep at all into MODBUS)
Correct. For the reasons stated in the previous post.
-
Also, everything I said only applies to Modbus *servers*. The Modbus *client* instructions MRX/MWX have no such limitations locally...since they are part of the Do-more controller, they can directly access everything in the controller.
-
Ok. That is what I thought.
-
Thanks. I just read all of the above in the *gasp* manual.
-
Thanks. I just read all of the above in the *gasp* manual.
Really?!? Wow...sounds serious. ;)
-
Just as a point of reference, the P3000 software looks like what I've attached here. Personally, I like the ability to map what you want, where you want.
Also, limiting the modbus registers has the downsides of both limiting the amount of data available over the interface (without constantly recopying data), and also taking memory away from the remainder of memory blocks.
I understand that this is not an issue for most use-cases, but 2048 << 65535.
-
.... and then I discovered you can change the size of the modbus block.
-
So really, now that I think about it, you can occupy all or nearly all of the memory space of the PLC with Modbus-readable memory locations. The only effective limitation is then what you call the things. If I want everything to be readable over modbus, I can do that, but they all have to have that funny prefix.
-
One feature that may be helpful is that you can have multiple Modbus/TCP Client (Master) devices defined in Do-more. Hence, you can have multiple Modbus/TCP transactions occurring at the same time (e.g. have 4 Modbus/TCP clients, and then spread your work across these 4 Clients to a set of slaves).
If you want to look at the next step, you could even "indirectly" address these Modbus Devices using the OPENDEV instruction of a "hard device" to a "Device Reference", taking indirection to yet another level. We did think of that - see the basic idea of "indirect devices" in the Simulator example "BatchData1.dmd" in the C:\Do-more Designer\Projects\Examples\Do-more Simulator folder. It just abstracts a batch report logger, one code-block logs to the "hard coded" PLC's @UserLog, another code-block logs to the "hard coded" @DmLogger application out the Ethernet port, the third code-block shows how to select dynamically at runtime where you want the logging to go via an X input - either to the PLC's log or DmLogger, using a common STREAMOUT instruction using a Device Reference, not a hard coded @userLog or @DmLogger like the first two code-blocks.
-
Just as a point of reference, the P3000 software looks like what I've attached here. Personally, I like the ability to map what you want, where you want.
It's really an apples to oranges comparison, although I can certainly see the utility. As a tag-based system, that's the only way P3K can make Modbus work, so it is really a necessity. In Do-more, you can essentially do the same thing using PUBLISH and SUBSCRIB, but unlike P3K, you don't have to if you don't want or need to. I don't know for certain, but it wouldn't surprise me that they take a pretty big performance hit with the random access maps, probably in the Modbus server itself. We also incur a performance penalty with PUBLISH and SUBSCRIB, but that really is optional, and can also be minimized to a great deal if you don't need the values updated every scan. Another benefit of PUB/SUB is the ability to do data manipulation while transferring values. It's not unusual with Modbus to need byte swaps or other conversions between internal memories and Modbus. We make that pretty painless.
Of course like all things in the engineering world, it's all about trade-offs. You choose your view of the problem and design to mitigate the limitations of your choices. Do-more's angle is high-performance low-cost machine control and that drove many of our choices...good or bad.
-
Maybe I'm missing something, but in the DL series, if you wanted to read a Vmem location, you found the address, calculated the offset from the beginning of the address block, converted number formats, and send a modbus read. There is no mapping required.
What I understood from the previous comment (and what makes sense, give the editable memory blocks and references), is that you have to explicitly map address locations to exposed modbus addresses. Is this correct?
No, it isn't a mapping issue where you map Modbus addresses to literal DM addresses. Protocols like Modbus and DL Classic protocols that lack built-in security are limited to accessing dedicated areas within a DM processor. The Modbus ones all start with "M", followed by abbreviations that refer to Modbus memory types. MHR is Holding Registers, MC is coils, etc. The DL stuff all starts with "DL" plus the DL memory type; DLX, DLY, etc. So if you set up a DL client and write to C1000, your DM program would have to be written to look at DLC1000, not the native C1000 in DM. Only native protocols that support the Do-More security model will be able to write directly to any address in the controller.
-
Just as a point of reference, the P3000 software looks like what I've attached here. Personally, I like the ability to map what you want, where you want.
It's really an apples to oranges comparison, although I can certainly see the utility. As a tag-based system, that's the only way P3K can make Modbus work, so it is really a necessity. In Do-more, you can essentially do the same thing using PUBLISH and SUBSCRIB, but unlike P3K, you don't have to if you don't want or need to. I don't know for certain, but it wouldn't surprise me that they take a pretty big performance hit with the random access maps, probably in the Modbus server itself. We also incur a performance penalty with PUBLISH and SUBSCRIB, but that really is optional, and can also be minimized to a great deal if you don't need the values updated every scan. Another benefit of PUB/SUB is the ability to do data manipulation while transferring values. It's not unusual with Modbus to need byte swaps or other conversions between internal memories and Modbus. We make that pretty painless.
Of course like all things in the engineering world, it's all about trade-offs. You choose your view of the problem and design to mitigate the limitations of your choices. Do-more's angle is high-performance low-cost machine control and that drove many of our choices...good or bad.
I understand, and I'm sure I can get what I want using a combination of extended MHR blocks and subscribe/publish features. I don't think I'll hit the ceiling, but if I do I'll be forced to do everything using MHR save duplicated data space.
-
I understand, and I'm sure I can get what I want using a combination of extended MHR blocks and subscribe/publish features. I don't think I'll hit the ceiling, but if I do I'll be forced to do everything using MHR save duplicated data space.
I used up all the memory on my last project (within 2k bytes), and so to get all of my user data blocks to display on C-mores, I copied data into reserved (C, V, and D) memory space for my 2 HMI's. I just monitored the pages the C-mores were displaying, as well as using scroll buttons and was able to display large databases on the screen using only about 60 tags (a person can only look at one page at a time right?).
What I'm saying is with the speed and instruction set of the Do-more, indexing/copying data is fast, easy, and reliable.
-
I understand, and I'm sure I can get what I want using a combination of extended MHR blocks and subscribe/publish features. I don't think I'll hit the ceiling, but if I do I'll be forced to do everything using MHR save duplicated data space.
It works just like any other memory block, other than security considerations, which may well not be an issue. I name pretty much every variable anyway, so whether the block is called 'V' or 'MHR' or 'Beauregard' I don't much care. I know some here are pretty adamant about using block names rather than symbols, but other than awareness of where they are located for comm purposes, I prefer to treat Do-more as a tag-based system. Of course YMMV...
-
It works just like any other memory block, other than security considerations, which may well not be an issue. I name pretty much every variable anyway, so whether the block is called 'V' or 'MHR' or 'Beauregard' I don't much care. I know some here are pretty adamant about using block names rather than symbols, but other than awareness of where they are located for comm purposes, I prefer to treat Do-more as a tag-based system. Of course YMMV...
I have mixed feelings on it. In DS, I found it quite annoying that the memory address locations were replaced by the aliases, since when writing code you could not enter by name. This was especially annoying in data view, because once you type in a memory address it is converted to a name and you can't click on it and have it convert to the memory address (as it does in the RLL screen). This problem has for the most part been mitigated by autocomplete and that you can in fact write variable names into the logic block fields. You may then effectively forget about where they are until you need to edit your memory blocks.
The one functional difference between this system and a solely tag-based one is that if I change the memory location in the memory editor, I assume that my code blocks will not automatically update with the new address, but instead will revert to either a raw memory address or whatever new alias the memory location has.
-
I have mixed feelings on it. In DS, I found it quite annoying that the memory address locations were replaced by the aliases, since when writing code you could not enter by name. This was especially annoying in data view, because once you type in a memory address it is converted to a name and you can't click on it and have it convert to the memory address (as it does in the RLL screen). This problem has for the most part been mitigated by autocomplete and that you can in fact write variable names into the logic block fields. You may then effectively forget about where they are until you need to edit your memory blocks.
In DS and in Designer, you can enable any/all documentation/element fields, but they cost you screen realestate, so the default in Data View is "nickname only" (which will display "element only" if NN does not exist), but you can check BOTH "nickname" and "element" or whatever to see EVERYTHING (right click on Data View, Options..., check the desired combination of Documentation fields you want, check the New Views checkbox in the Apply To group at the top so that your changes will be applied to any NEW data view instances that come up).
The one functional difference between this system and a solely tag-based one is that if I change the memory location in the memory editor, I assume that my code blocks will not automatically update with the new address, but instead will revert to either a raw memory address or whatever new alias the memory location has.
You are correct. The element is stored in the instruction, not the nickname. However, there is a Replace utility in both DS and Designer below the Search-> menu that can be helpful when needing to "move" a "tag" across ALL ladder logic.
-
I have mixed feelings on it. In DS, I found it quite annoying that the memory address locations were replaced by the aliases, since when writing code you could not enter by name.
Unless something is broken, nicknames can be typed into any element entry field in DS. Of course without auto-complete, that is a bit more of a chore, but for a tag-centric developer, you shouldn't need to use element names in DS or DM.
The one functional difference between this system and a solely tag-based one is that if I change the memory location in the memory editor, I assume that my code blocks will not automatically update with the new address, but instead will revert to either a raw memory address or whatever new alias the memory location has.
Correct. The key distinction between true tag-based systems and conventional memory-based systems is that we store a memory location rather than a tag handle. As was previously mentioned though, there is a powerful replace facility for dealing with those issues. Personally, I don't find it to be an issue because I shy away from elements except for comms where I must know. I would think you wouldn't need to change addresses very often, except in the case you are refining a public comms interface where the order and placement is important. Of course PUBLISH and SUBSCRIB is a great way to handle that...but requires a copy...and our merry chase has just looped back on itself!!
Again...there's always trade-offs. If engineering was easy, it wouldn't pay quite so well. ;D
-
I just got a DoMore in the mail today. What does the time-frame look like implementation of this feature?
thanks.
C
-
We opted to go ahead and implement variable IP for all remaining network instructions as well as a DNS lookup instruction. It will be a week or two, although probably two once we get it all tested.
-
Excellent. Please keep us posted.