I know that it’s ideal with have each module on an EPIC rack communicate with a single control program, but there are cases where it is very convenient to share a single input module between two controllers.
Assume I have PLC_A and PLC_B, each of which is an EPIC-PR1 on a CHS-0 with no local I/O. I also have REMOTE_C, which is an EPIC-PR1 not running any sort of control strategy but with various I/O modules attached.
The first position on REMOTE_C contains a GRV-IMAI-8 module with a field device wired into each of the eight channels. The first four devices are used by PLC_A and the last four are used by PLC_B. I’d like to be able to configure my channels through Groov manage (signal type, scaling, etc.) and then connect to the device with CODESYS without configuring the rack each time I do a download. I don’t want to have to configure the four channels for PLC_B in PLC_A and vice versa just to avoid overwriting settings on download.
When I configure the remote I/O rack in CODESYS, there is an option to set Enable Configuration to FALSE for the EPIC device. The comments say that disabling configuration will also disable configuration to all child modules. This sounds like what I want. I’m running the newest firmware on my EPIC (3.6.0) and I’ve updated to the newest Opto22 library in CODESYS. Any time I set Enable Configuration to false, I get an error and cannot download the program. The details dialog shows an access violation and reports the code position as IoDrvOptoAnalogInModule.SendChannelConfig.
Am I doing something wrong? Is what I’m hoping even possible?
I do know that if I change the configuration in Groov Manage after a download from CODESYS, CODESYS reads the updated EU from the analog input module. However, the configuration is overwritten by the next download.
I would not recommend having 2 PLCs control a single remote I/O unit. You are correct in that whatever the last download was will be what is used in the parameters. You should stick to a single source of truth(Only one master downloading parameters) when doing this with hardware.
I am unsure why the disable configuration is not working for you, I am getting the same error, so I have passed that on to our team.
If you need to do this a better method would be to use the MMP functions for the 2nd PLC to access the points.
@greichert: where do I draw the line? Should it be only one controller accessing an entire EPIC rack, or is keeping each module to a single controller adequate?
While I understand what you’re saying in terms of a single source of truth, if the disable configuration option were working, would my original idea theoretically work?
Perhaps it’s a good time to review your thoughts from November 2021…
The whole thread is worth a re-read.
I asked @greichert if Codesys had something like the generic MMP IO device, and he said he’d think it over. But the core principle remains: You can have as many controllers accessing the I/O as you like.
The key to remember is that the last I/O configuration sent / downloaded ‘wins’.
Same with PAC Control and groov Manage. We have people that setup their I/O via groov Manage in a web browser and then wonder where it all went when they download PAC Control.
Some change the PAC Control config via groov Manage and it works fine for months, then the controller power cycles and their groov Manage changes are overwritten, but it was so long ago, that they can’t figure out what changes they had made via the web browser.
The generic MMP device is just a way to try to make it read-only and save a bit of that hassle, but you don’t need it. It all comes down to documentation and teamwork (if you have more than one person working on your control system). Module per control system, entire I/O, or read-only, it’s your call.
@beno: I appreciate the perspective. I remember previous conversations, but I was wondering if CODESYS offered a different path since it offers an option to configure an I/O rack without configuration (though that doesn’t seem to work at the moment). I don’t think PAC Control has an equivalent setting. If I could configure my I/O in CODESYS without configuration and make Groov Manage the single source of truth for I/O configuration, I guess I was hoping I could have my cake and eat it too.
I guess that’s where I was going with my follow-up question: if I segregate the field devices attached to REMOTE_C to the point where everything attached to module 0 is for PLC_A and everything attached to module 1 is for PLC_B, and each PLC only defines the modules for the devices it directly controls, is there a risk of either PLC overwriting configuration from the other? In CODESYS, I would define the rack on each PLC, but then on PLC_A I would “plug a device” in CODESYS into module 0, and on PLC_B I would “plug a device” in CODESYS into module 1. When I download to PLC_A, does it do anything to the configuration of module 1 even though it knows nothing about a module plugged into that position?
It depends on what you are wanting to accomplish. A typical install would be one controller and its I/O and remote I/O racks. These would control the machine or process that is being automated. If a second machine or process would need automating, it most likely would be done with a second controller and its I/O and remote racks. Now in some cases, if the controller can handle it, you could use 1 to controller for both machines/processes. It is very much the outlier in industry to have multiple controllers all accessing the same remote I/O racks(unless done for redundancy hot/warm).
In practice your idea would work(we are looking into the issue). My concern would be with maintaining this system. If you are not there, would someone else be able to troubleshoot it using only the physical documentation? What about in 5 years? I fall back to my experience in the field for these things.
I wouldn’t recommend operating this way, but in PAC Control, you would set the IO unit “Enable communications from control engine” to be unchecked in the configuration, call SetIOUnitConfiguredFlag in the power up chart, then call EnableCommunicationToIoUnit. This should prevent the strategy from modifying the IO unit configuration. You would need to check if you need to call that command before any call to enable communication (like in and IO enabler chart).
I would lean towards MMP or scratchpad commands to avoid having to maintain IO configuration in multiple strategies.
