Reading or Writing BITs with MSG instruction

Summary: How to remotely toggle BOOL values on a vendor-supplied system having a L24ER PLC?


(RSLogix Studio 5000 version 33.01.00)


I have a L30ER PLC from which I want to poll the L24ER for various tags.


I can't modify the program in the L24ER vendor-supplied system.


However, I must create a HMI and also telemetry that talks to our main control station, that interacts with my PLC, but which also allows the user to change some settings in the vendor-supplied PLC. For example, wetwell level settings, pump enable/disable, auto/manual, etc.


I can access the vendor's PLC with RSLogix5000 and export their UDTs which store this info. Thus I can *read* this data using the MSG instruction, into an identical tag in my PLC.


However, since the MSG instruction does not support BOOL tags, how can I set a single bit in the vendor's PLC for such things as Pump Enable, Auto, etc?


I'm not comfortable writing back the entire UDT, because some other values are directly tied to process values that their PLC reads (i.e. wetwell level, pump speed, etc). Since there are several tags to read, I want to decrease the read frequency to reduce network congestion (i.e. 10+ seconds between reads). So by writing back the full UDT, I would be writing outdated values (at least 10 seconds old) into their tags, for the sole purpose of toggling a single bit. This doesn't seem like a good idea, especially if someone changed settings directly in their PLC between reads/writes on my end.



Is there a way to solve this without modifying their PLC's program? I need to be able to simply toggle individual bits in their controller from mine.



The easy solution would be to either set up produced/consumed tags, or add some INTs to their program and map individual bits back their UDT, then I could write to those INTs directly with MSG. However, either option would require changing their program.



Thanks for any pointers.

Let's start by breaking assumptions.
Are these assumptions real, or can they be traded off?
1)Modifying manufacturer's PLC project.
2)Reading the entire UDT every (as fast as possible)ms.

Other options are, using an OPC system? You can connect the PLC to an OPC system and use that to write to BOOL values?
You can even have it so that your PLC's BOOL values are directly coupled to the vendor PLC's BOOL values. This would mandate and OPC server though. Making the first tradeoff and creating the prod/consumed tags would be what I would push for.

Regards,
-PreLC

@PreLC
Thanks for your reply. I like your out-of-box thinking.

I'm probably going to have to modify the vendor's PLC code, but I am very hesitant because if anything breaks, they're going to blame me. haha, what else is new.



It's insane that Rockwell would disable the ability to read/write individual bits in this way, just because some people would misuse the ability. That's just like... well, a lot of things... never mind.


I like the idea of an OPC client but you're right, it adds more complexity and dependencies to the project. I think the small size of this project precludes making it any more complex than it already is.


I hate to take the vendor's PLC offline to add Produced/Consumed tags, but I don't know a way around that, and the download should only take a few seconds. Should be able to do this during a period of low activity.





Thanks for your input.

I have un-farked dozens, maybe hundreds, of MSG instruction logic programs in my career. It would be thousands if BOOL reads and writes were allowed.

For better or for worse, they aren't.

The only "workaround" is the one you already know about: "read-modify-write" of the whole UDT.

Or, have them break out the inter-system tags into some DINTs that are just for that purpose. Preface them with your company initials, or put them in a separate Program scope. Submit every single rung or tag you change in their system as a document to them to minimize fingerpointing.

I appreciate that "last one to touch it gets blamed" but you'd be there if you addressed any sort of MSG instructions to their controller anyhow.

@ken
Thanks Ken. Sounds like I'll just have to bite (or dodge, hopefully) the bullet and modify their code. Good idea on the documentation.

Why you just run it by the OEM what you want to do, hard to how to proceed easily without adding a couple of tags. It’s also your machine.