Can SNAP PAC system auto detect I/O modules? - old forum post

Other Opto Products
1

nvl

Joined on 07-12-2007
Posts 19
Can SNAP PAC system auto detect I/O modules?

Our customers ask the questions regarding I/O modules:

  1. Do PAC controller R-series & Brain automatically detect the I/O modules upon they are plugged (hot plug)?

  2. Can PAC Manager or PAC control diagnostic the status of I/O Modules?

             - to see whether it still works or break few channels.

         - to see Quality of I/O signals

…

Report 
11-08-2007, 5:34 PM

kdowney

Joined on 05-10-2007
Opto 22
Posts 28
Re: Can SNAP PAC system auto detect I/O modules?

  1. Brains or rack mounted controllers do not auto detect an I/O module but this is partly because they do not need to. When you create the configuration (either in PAC Control or PAC Manager), you tell the brain or rack mounted controller what module should be there. The brain or rack mounted controller does not really know if the module is there or not. Also, we do not recommend hot swapping modules. Without hot swapping, there is no need for an auto-detection you speak of.

  2. A way you can monitor the state of I/O modules is to create logic in your strategy that will monitor the quality of the I/O. Things you can check for are if the value goes out of range or does not change within an expected time frame.

-Kelly D.

Report 
11-12-2007, 7:04 AM

nvl

Joined on 07-12-2007
Posts 19
Re: Can SNAP PAC system auto detect I/O modules?

Dear Kelly,

Thank you. Hope our customers satisfy with these answers.
Report
11-14-2007, 9:58 AM
gmitchell

Joined on 12-01-2003
Optomation Systems, Madrid, Spain
Posts 153
Re: Can SNAP PAC system auto detect I/O modules?

Kelly.

I would actually debate this one. SNAP PAC I/O can be referred to as “The Mother In-Law of all I/O systems”. Let me explain.

SNAP Analog I/O modules and high density actually know full well who they are and where they are on the rack. But they prefer not to say anything while you get on with the work of configuring them on the rack using PACControl or an OTG file.

If you do not make any mistakes then they keep quiet, but if you get one tiny thing wrong, (module type, position etc) then they are more than happy to loudly tell everyone that you don’t really know what you are doing. Finally they convince the PAC Brain not to enable communication with the whole damn SNAP Rack.

Does this situation sound familiar to anyone?

Report 
11-15-2007, 8:43 AM

kdowney

Joined on 05-10-2007
Opto 22
Posts 28
Re: Can SNAP PAC system auto detect I/O modules?

George,

You are correct. I should have clarified my answer. When changing identical modules, (taking a bad one out and then replacing it with the same module type) there is no need for auto detecting.

Thanks.

-Kelly

Report 
02-19-2008, 6:14 AM

Joshua

Joined on 06-09-2005
Posts 6
Re: Can SNAP PAC system auto detect I/O modules?

gmitchell wrote:
If you do not make any mistakes then they keep quiet, but if you get one tiny thing wrong, (module type, position etc) then they are more than happy to loudly tell everyone that you don’t really know what you are doing. Finally they convince the PAC Brain not to enable communication with the whole damn SNAP Rack.

I could be mistaken, but this is due to memory address issues, ie it’s not that the module says “i’m X at position Y” but that you send something to an address that doesn’t exist when the module isn’t present.

Report 
02-19-2008, 2:29 PM

gmitchell

Joined on 12-01-2003
Optomation Systems, Madrid, Spain
Posts 153
Re: Can SNAP PAC system auto detect I/O modules?

Thanks for reading the thread and participating. The OptoForum needs more of this open debate

I understand what you are thinking, but all SNAP modules can be addressed 0-15 on the rack. Each I/O module has its own address. Sixteen modules can be addressed per communications link. Modules are addressed 80 through 8F hex.

4ch digital modules do not need this feature as they require no protocol; they are simply read or written to using 5VDC signals.

Analog modules, special modules and all HighDensity I/O modules are “smart” that identifies its module function. Each module is is actually an addressable analog processor that you can communicate with using either ASCII or binary serial modes.

Pins 1,3,5,7 on the module will connect to define the module address. What’s not so obvious is that the module address is not set on the module, but on the rack when plugging the module into the connector. You can study much more about this by reading the SNAP IO Module Integration Guide.

http://www.opto22.com/site/documents/drilldown.aspx?aid=1679&title=SNAP+I%2FO+Module+Integration+Guide

Analog modules know exactly who they are, you can read this by sending them a command 46 (Identify Module Type) using the SNAP IO Module protocol. That’s part of whats happening when you “configure” the I/O and enable communications on startup. You just don’t see it as it’s hidden within PACControl. But you do see the result if the I/O does not match the configured version, in that the brain will not enable communications because of a module mismatch.
Also the whole possible I/O is completely memory mapped in the brain, (rather like a computer BIOS) whether the modules exist or not. The addresses are predefined. Whether they contain data depends on whether a module has been plugged in. Use PACManager to understand the complete addressing possibilities. You may like to take a look at the Opto 22 hardware memory map section in the MMP Protocol Guide to fully understand the mapping. Its a pretty complex thing!

http://www.opto22.com/site/documents/drilldown.aspx?aid=1875

Hope this information helps. Generally the more you study the PAC and SNAP Product Lines, the more you understand that it’s the most technically “pure” product in the market and has already resolved issues that you haven’t even considered yet! Don’t forget Opto 22 has been continuously developing I/O product lines for the past 30 years, so they do have a slight advantage!

2

Sorry for reviving a very old thread, but it is related to my question.

As a simplified example, I have three physical hardware configurations for a SNAP-PAC-R1 controller with I/O modules. The first configuration controls blowers, the second configuration controls pumps, and the third configuration controls both blowers and pumps. What I want to do is have one Strategy with one logical I/O configuration regardless of the actual physical I/O modules present. So, to summarize, here are the three physical hardware configurations:

Configuration A

Module 0 = SNAP-AITM-8 for 3 temperature sensors related to blowers
Module 1 = SNAP-AOV-25 to control blowers
Module 2 = SNAP-AIV-8 to read blower speeds
Module 3 = Not Used (empty)

Configuration B

Module 0 = SNAP-AITM-8 for 2 temperature sensors related to pumps
Module 1 = Not Used (empty)
Module 2 = Not Used (empty)
Module 3 = SNAP-ODC5SRC to control pumps

Configuration C

Module 0 = SNAP-AITM-8 for 5 temperature sensors related to blowers and pumps
Module 1 = SNAP-AOV-25 to control blowers
Module 2 = SNAP-AIV-8 to read blower speeds
Module 3 = SNAP-ODC5SRC to control pumps

So, my plan is to write one Strategy with the I/O configuration set to physical Configuration C above. However, if the Strategy is actually running in physical configuration B, the blower speed values are not valid. So, the Strategy will test for that, see they are not valid, and ignore them. The same goes for the Module 0 temperature sensors related to blower control, which aren’t there in physical Configuration B.

I am not hot-swapping anything and the physical hardware configuration doesn’t change after it is initially created. In other words, Configuration A, B, and C are three different products. I’m just trying to cut the development down to one Strategy that runs in all three physical configurations.

Am I going to run into any problems that can’t be tested for and overcome by Strategy logic by doing this?

3

Hi Don,

Did you come across this post?
Seems like it covers some very similar ground?

http://www.opto22.com/community/showthread.php?t=428

Ben

4

Hello Don,

Interesting question. The part that concerns me is when you mention: “values are not valid.” This could happen because you have no module plugged in OR because the rack has insufficient voltage to it, as Ben explains in this video.

Typically that value would be whatever you have configured at this mem map location (default: -32768). While you’re there, note the mask that gives you a little information about which module positions have an ANALOG (or serial) module plugged into them:

While that value “Smart Modules Present” might be less likely to get messed up by too-low voltage, electrical noise, etc. (which can mess up your analog input readings), there’s no way to “detect” that digital module.

I’m wondering if you might just want to configure your own A/B/C value in the mem map, or in a persistent variable, as part of the setup. For example, if you had a persistent variable in your strategy called nConfigurationFlavor, you could go into debug when you first download that strategy and set it to 1, 2, or 3 then check for that value in your strategy (rather than checking for a “bad” input value). Or, you might write that value into some pre-determined mem map address.

If it were me, based on the little I know, I think I’d leverage the Scratch Pad Area of the memory map and do something like this:

  1. Add code in your "common" strategy that read the first, say, 5 Scratch Pad Strings into a persistent string table in that strategy. Let's say element 0 will store the Configuration Type and the other 4 elements are for notes. If element 0 is empty, then add and error in the queue, alert the masses, or whatever appropriate error handling is best for your system. If you do put an error in the queue (or in an email, or wherever), make sure it's detailed enough to remind your future self what to do to correct the problem, e.g.: "Expected an A or B or C in the first element of the Scratch Pad Strings."
  2. When you go to "commission" your product, assign that SNAP-PAC-R1 an appropriate IP address and fill in the appropriate values in your scratch pad strings, and don't forget to "store to flash" in PAC Manager. I'd make use of those extra few strings to make a note about where the R1 is located, perhaps... and/or the date of the initial installation? Any other "notes to self" (or others) that might be helpful? Maybe your email address?
  3. In your strategy, if you're seeing "values that are not valid" (and they[I] should[/I] be based on what was read in from the mem map SP for the configuration), put an error in the queue/alert the masses/appropriate error handling... because that could mean the power supply on the rack is dying or maybe someone is welding or causing a crazy amount of electrical noise near the modules.
In summary: DON'T ASSUME bad value = no module. Also, I love that you're building "reusable code" here--much more maintainable like we talk about in [this video](http://www.youtube.com/watch?v=D5KAn9W-ePg).

Whatever you decide to do, be sure to write comments explaining your intent!

-OptoMary

5

Ben and Mary,

Thanks for the additional information! Also, nice job on the videos.

Let me provide a little more detail on my Strategy while still trying to simplify it. I do have a configuration variable called “hwConfig” which is similar to what Mary describes. It is set, along with some other variables, using a comma-separated text file that is transferred to the R1 using ftp. The R1 then converts data from the file into persistent variables.

In my Strategy, I have two equal-length numeric tables called PNT_Value and PNT_Enable. At the start of my chart that scans I/O point values, I first check to see if the hwConfig variable needs to change. If it does, I do something like this:

// Check for hardware configuration change in the text file
if (newHwConfigFromFile != hwConfig) then

// Values for enabled or disabled I/O points
PiontEnabled = 1;
PointDisabled = 2;

// I/O Point Indexes
Idx_tempAirIn = 0;
Idx_tempAirOut = 1;
Idx_pressWaterIn = 2;
Idx_pressWaterOut = 3;

// Configuration A
if (newHwConfigFromFile == 1) then
hwConfig = newHwConfigFromFile;
PNT_Enable[Idx_tempAirIn] = PointEnabled;
PNT_Enable[Idx_tempAirOut] = PointEnabled;
PNT_Enable[Idx_pressWaterIn] = PointDisabled;
PNT_Enable[Idx_pressWaterOut] = PointDisabled;
// Configuration B
elsif (newHwConfigFromFile == 2) then
hwConfig = newHwConfigFromFile;
PNT_Enable[Idx_tempAirIn] = PointDisabled;
PNT_Enable[Idx_tempAirOut] = PointDisabled;
PNT_Enable[Idx_pressWaterIn] = PointEnabled;
PNT_Enable[Idx_pressWaterOut] = PointEnabled;
// Configuration C
elseif (newHwConfigFromFile == 3) then
hwConfig = newHwConfigFromFile;
PNT_Enable[Idx_tempAirIn] = PointEnabled;
PNT_Enable[Idx_tempAirOut] = PointEnabled;
PNT_Enable[Idx_pressWaterIn] = PointEnabled;
PNT_Enable[Idx_pressWaterOut] = PointEnabled;
// Invalid
else
// (Do error processing)
endif
endif

The PNT_Enable table marks each I/O point as enabled or disabled. Then, I transfer the actual I/O point values to the PNT_Value table doing something like this:

// Disabled and invalid float values
DisabledFloat = 911.1;
InvalidFloat = 999.9;

// Air In Temperature I/O Point (TempAirIn)
if (PNT_Enable[Idx_tempAirIn] == PointDisabled) then
PNT_Value[Idx_tempAirIn] = DisabledFloat;
elseif (TempAirIn >=0 AND TempAirIn <= 65)
PNT_Value[Idx_tempAirIn] = TempAirIn;
else
PNT_Value[Idx_tempAirIn] = InvalidFloat;
// (Then generate an Error and do error handling)
endif

Whenever I use an I/O point value, I first check to make sure it is enabled and valid:

if (PNT_Value[Idx_tempAirIn] < DisabledFloat) then
// (Implement automatic blower control based on Air In Temperature)
endif

So, am I risking a problem by having a common Strategy where the I/O Units -> Configure… setting is set to the fully-populated I/O module configuration, but the Strategy may be running in a system where the physical hardware for some of the I/O modules actually isn’t there? In other words, is it possible the R1 could disable the I/O unit because it detected that the physical hardware wasn’t there to match the logical I/O configuration?

Is there any other “gotchas” that I don’t know about? What if someone changes the hwConfig variable after the system is running?
Is there a potential problem if the Strategy tries to write to an output point that physically isn’t there but is defined in the I/O Units -> Configure… setting?

These are obviously things I will test thoroughly when we have hardware in a few months. But, I’d like to see if anyone knows of
potential problems with my plan now. If there are problems, I will have to re-think the plan. I’ve done some testing on a controller by removing modules (with power off) and restarting the Strategy. I’ve only seen an initial start-up Error message in PAC Control that the hardware didn’t match the configuration, but things still worked.

6

Wow, sounds like you’ve got a good, well-thought-out plan. Not sure what to say about someone potentially changing hwConfig after the fact. How might that happen? There are various levels of “protection” you can use to make sure folks don’t mess with your system, but which/how many too use could vary widely based on a number of considerations.

I’m assuming that “initial start-up Error” you mentioned was the -35 warning you’ll see in a PAC’s message queue when you first run your strategy? That’s the only place I can think of where the control engine checks to see if what you configured in your strategy matches what’s in the memory map’s “Point Type” value, for analog points/modules. It’s just a “warning” on purpose so you can do things like what you’ve described.

The only other piece of information that might be important for you to know, is to use caution when comparing floats. For example, I see you’re comparing your DisabledFloat value to another value. The sample code you shared looked okay, but be sure not to check for equality, because with floats you might miss when 2 values are “equal” (they might be really, really close and appear to be equal) due to (essentially) rounding errors. More on the topic of Using Floats in this tech note (form 1755).

Hope that helps!
-OptoMary