Optomux in PAC

Is there anything developed to talk via Optomux to B1 & B2’s in PAC Project? I noticed that PAC-INT-OMUX is not available. Has it been replaced?

I have customer facilities that make it difficult to get Ethernet in to replace the serial communications. I need a solution at least for an intermediate term until new comms can be run.

Hmm, wonder why the integration kit isn’t there. I have a copy of it somewhere around here if you need it before they fix the link. Hopefully they still have it available.

We took it down because it was Really Ugly. You’re better off w/a simple example (I have one of those around on the OptoForums somewhere too).

But we also have a tech note that tells you how to use an E1 as an Ethernet to Serial gateway, so you can communicate via Ethernet from your PC to one E1, then have that communicate via 485 to your old B1s. That could be phase one of your intermediate solutions? We also have built-in E1/E2 support in PAC Control on the horizon. What’s your timeframe and what are you upgrading TO and FROM exactly?

Do you have a link to that technote? I didn’t know an E1 could act as a gateway to optomux.

Yes! And a few other links that might be helpful…

Using first E1 as “gateway”:

“Migration” doc:

Configuration note – won’t be needed when built-in PAC Control E1/E2 support comes out.

Okay, for some reason my brain jumped to thinking the E1 would bridge OptoMMP over to Optomux with rainbows coming out the other side. Now I see that Optomux will still need to be used, it’s just done over ethernet.

I have quite a number of Paragon-B1/B2 systems out there. Most, I plan on changing the B’s to E’s and move the logic to a rack mounted SNAP. Some of the facilities aren’t that easy. I don’t have any in the works just yet but wanted to be ready.

If I had B100/B200’s I could stick with the serial, but E1/E2’s only talk Optomux on the serial port so I’m stuck with that unless I change out both the brain boards and the comm structure. The complication comes from the distances between Paragon and the various enclosures with B1/B2’s or the distance between enclosures, distances that will require fiber. I’m just thinking of ways to make these upgrades a little more economical. Even without the cost of upgrading comms, I would like to give customers an intermediate option to replace Paragon for a SNAP processor but upgrade to E1/E2’s in stages.

Not sure if you got my PM with the old Optomux subs.

I have a SNAP S2 talking Optomux using those subroutines and it has been working good for 4 years now. I have a chart that builds the configuration string for the subs and I write all my initial configuration to tables like this:


//**************
//Configure IO Points
//**************

/*
stLPointName - Name of the point - for display, error, and logging.
ntLPointBrain - The index of the brain this point is located on.
stLPointType - The type of point, DI, DO, TI, AI, AO, DL (DI latching)
ntLPointChannel - The brain board channel of the point
ntLPointAnalogLow - The analog low scale value
ntLPointAnalogHigh - The analog high scale value
ntLPointTempProbeType - Optomux temp probe type (See optomux docs)
ntLPointVariableIndex - The index that the points data is read or written to if pointing to an array. (-1 if not)
potLPointVariable - Address of variable to read/write the point to.
potNLPoint - Point name of the IO point for points that have been upgraded from the legacy IO boards
*/

stLPointName[0]="TT108 WC011 RmT";
ntLPointBrain[0]=5;
stLPointType[0]="TI";
ntLPointChannel[0]=1;
ntLPointTempProbeType[0]=1;
ntLPointVariableIndex[0]=0;
potLPointVariable[0]=&ioftLZoneSensor;


stLPointName[1]="TT112 FL107 RmT";
ntLPointBrain[1]=18;
stLPointType[1]="TI";
ntLPointChannel[1]=0;
ntLPointTempProbeType[1]=1;
ntLPointVariableIndex[1]=1;
potLPointVariable[1]=&ioftLZoneSensor;


stLPointName[2]="TT113 FL108 RmT";
ntLPointBrain[2]=18;
stLPointType[2]="TI";
ntLPointChannel[2]=1;
ntLPointTempProbeType[2]=1;
ntLPointVariableIndex[2]=2;
potLPointVariable[2]=&ioftLZoneSensor;

That goes on for another 160 points or so… This was one of my first Opto projects, so it may be ugly in places, but it works! I generate this code from a spreadsheet to make adjustments/changes easier. Let me know if you would like me to help you out with that.

Philip

Thanks Philip, I will take a look and let you know if I have any questions. Doug

So, I was finally able to start work on this…

I’ve got it all set up and working but have started to test the system error handling. I’ve got two main potential issues with communications: first is getting the boards reconfigured/outputs re-set after power outage and second is dealing with loss of communication with one or more boards while maintaining control of the rest of the boards on that serial port. Dealing with PUC is taken care of. But, if I disconnect comm wire to one brain, I get a ~30 second timeout. This is after a TransmitReceiveString() command (and a -58 error code) used in the OPTO22 Optomux subroutine. In the help documentation, it says this should timeout after ~10 seconds. It would be good if this was down to 1 second but 30 seconds is way too long to wait for comm error response. I need to be able to continue communications with the rest of the boards sooner than that. Anybody have an idea that would shorten this delay? Thanks, Doug

For the re-configuring outputs, are you calling the OM_RE_CONFIG_IF_POWER_FAIL subroutine? I do this every time I go through my poll loop.

My communication handle has the timeout in it: ser:port=2,baud=9600,data=8,parity=n,stop=1,timeout=0.3
Maybe that will fix your timeout issue? As you can see by my timeout setting, I don’t want to wait long.

Thanks Philip,

I’m using an SCM-485-422 module with an R2 processor. tcp:192.168.5.240:22514 to set up the comm. handle. I don’t see in the manual that I can setup the tcp port like an onboard serial port (with timeout adjustments). Looked in the PAC Manager setting changes allowed for that module and didn’t see that feature. I see some tcp settings in PAC Manager for the R2 that might allow timeout adjustments.

Okay, never used a serial module before, but since the PAC is essentially talking tcp here, you would have to handle the timeouts like a tcp connection. I normally use a timer variable, which the optomux subroutines don’t do (they use the TransmitReceiveString command that relies on the timeout of the underlying connection)

You can try changing the tcp receive timeout with the SendCommunicationHandleCommand command. You would need to call this BEFORE you call one of the Optomux subroutines so that your chart opens the comm handle instead of the subroutine. I’ve never used this command before, but it looks like this is it’s intended use.

if (IsCommunicationOpen(MyCommHandle)) then  //Comm handle already open, timeout Should already be set (unless something else opened it)
else
    Status = OpenOutgoingCommunication(MyCommHandle);
    if(Status == 0) then
      //Open successfully, set timeout to 1/2 second
      Status = SendCommunicationHandleCommand(MyCommHandle, "set.to:0.5");
      if(Status < 0) then
        //Something went wrong
      endif 
    else
      //Something went wrong
    endif
endif

Let me know how it goes, because I may be using one of these modules on an upcoming project and would like to be able to control the timeout.

(You can also add the SendCommunicationHandleCommand to the subroutines where ever they open the comm handle. As a general rule I try not to modify 3rd party subroutines, but I don’t think this one is going to get any updates in the future.)

Thanks Philip, that did it.

You asked above “For the re-configuring outputs, are you calling the OM_RE_CONFIG_IF_POWER_FAIL subroutine?” I am checking the PUC flag after every subroutine call. Although it required some additional logic in the subroutines because comm errors caused the same result as power failure. Then if flag is zero, I call OM_CFG_ALL_16_I_O_POSITIONS for that brain board address. I also added some tables that: disable comm with individual brains, keep track of error counts and type per brain. This should help identify individual brains that are not communicating and/or causing other brains not to communicate.

Happy to help.

I did similar bench testing as you on my optomux project and don’t remember ever losing the config when I pulled comm wires. I wonder is something else is going on??

Sounds like a good plan. I only keep track of the brain status for each brain and show that in the HMI. Useful to track down a broken comm wire or more likely a dead power supply/local panel power outage.

[I]“comm errors caused the same result as power failure” [/I]is confusing[I][/I].

When pulling comm wires, I was getting a re-set of the PUC flag to zero and comm error set to 10 out of the OM subroutines. So, comm failure looked like a power failure. This was sending my logic to call OM_CFG_ALL_16_I_O_POSITIONS which compounded (x16) my extended timeout issue.