Parameterized network master instructions

[CReese]

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

[BobO]

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.

[plcnut]

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?

[CReese]

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.

[CReese]

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.

[Controls Guy]

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  ).  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.

[CReese]

Can somebody point me toward info on these custom protocols you speak of?

[Controls Guy]

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 from the horse's mouth.

[BobO]

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.

[CReese]

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

[BobO]

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.

[CReese]

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?

[Controls Guy]

@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.

[BobO]

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.

[CReese]

@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