SNAP Hardware ID codes


#1

Hey ya-

I’m looking for a list of values for hardware id numbers that would be listed as return values for the MMP functions GetStatusHardwareEx and GetStatusHardwareEx2, as described in the document 1465_OptoMMP_Protocol_Guide.pdf, on page 82. I know a few of them, but I’m looking for a complete list. One example of one I know is the SNAP-PAC-R2 returns a 0x78 (decimal 120).

I’m writing some code that will enable or disable some feature (like on-board counters) based on the equipment installed, and would rather not have to discover them all by experimentation. :slight_smile:

Thanks!
Todd++;


#2

Hi Todd++

Welcome to the forums. I’ve got a few questions of my own to make sure I’m getting you the answer(s) you need. I suspect you just need to click your heels together 3 times and search form 1465 for the phrase “unit type.” (I also think your version of that doc might be older than the PDF I find today on the website, because the function you mention is on a slightly different page.)

That function reads address F030 0020 which could currently be one of these (more hardware types are sure to be added in the future), as shown on page 119 of the current Appendix – Status Area Read—Read Only:

[LEFT][SIZE=1]0x00000052 = OPTOEMU-SNR-DR2[/SIZE]
[SIZE=1]0x00000056 = OPTOEMU-SNR-DR1[/SIZE]
[SIZE=1]0x00000058 = G4EB2[/SIZE]
[SIZE=1]0x0000005A = OPTOEMU-SNR-3V[/SIZE]
[SIZE=1]0x0000005C = SNAP-PAC-SRA[/SIZE]
[SIZE=1]0x00000062 = SNAP-PAC-SB2[/SIZE]
[SIZE=1]0x00000064 = SNAP-PAC-SB1[/SIZE]
[SIZE=1]0x00000066 = SNAP-PAC-R2-W[/SIZE]
[SIZE=1]0x00000068 = SNAP-PAC-R1-W[/SIZE]
[SIZE=1]0x0000006A = SNAP-PAC-S1-W[/SIZE]
[SIZE=1]0x0000006C = SNAP-PAC-S2-W
0x00000070 = SNAP-PAC-EB2-W
0x00000072 = SNAP-PAC-EB1-W
0x00000074 = SNAP-PAC-EB2
0x00000076 = SNAP-PAC-EB1
0x00000078 = SNAP-PAC-R2
0x0000007A = SNAP-PAC-R1
0x0000007C = SNAP-PAC-S1
0x00000083 = SNAP-ENET-S64
0x0000008A = SNAP-UPN-ADS
0x0000008C = SNAP-UP1-M64
0x00000092 = SNAP-UP1-D64
0x00000093 = SNAP-UP1-ADS
0x00000094 = SNAP-WLAN-FH-ADS
0x00000097 = SNAP-ENET-D64
0x00000098 = SNAP-B3000-ENET or SNAP-ENET-RTC
0x000000E1 = E1
0x000000E2 = E2
0x00000193 = SNAP-LCE[/LEFT]

[FONT=Verdana][SIZE=2]But I doubt you need all that. Do you have PAC Manager installed? Are you connected to a network with all your Opto 22 devices on it? If so, you can use the “find” feature by selecting the menu option: Tools > Find Opto MMP Devices then click the “Find” button. [/SIZE]

The resulting list includes this “Unit Type” column on the right. I’m guessing the number of hardware types you’ll need to support will be a much shorter list.


[SIZE=2]Also, while you’re in the “Status Read” section of the Appendix, you might want to check out some other values that could be useful to you for figuring out what kinds of hardware you’re talking to. For example, as you can also see in PAC Manager if you go to: Tools > Inspect and click “Status Read” (then scroll down a little) there’s this value:

0xFFFF F030 007C Smart Modules Present 0x009C (analog, serial, etc.)

If the device I read this from had no analog modules installed on the rack, that value would’ve been 0. Instead, I’m looking at a bitmask representing where I do have analog/serial or high-density modules plugged in. Since that 0x009C is 10011100 in binary, reading from the right I know I have those modules in slots 2, 3, 4, & 7. Unfortunately, there’s currently no value in the memory map indicating where you have a 4-channel digital module plugged in – does look the same as an empty slot.

Hope that helps. Can you tell us more about what you’re doing? Sounds interesting! If
you’re limiting options for user selections, do you need to worry about future types of hardware that could be added into the system later? There might be ways we could help future-proof your code so it’ll still work when you expand…

-OptoMary[/SIZE][/FONT][/SIZE]


#3

That first list is precisely what I was looking for- I had searched the document, I just didn’t use the right phrase- I think I tried ‘unit id’ and ‘pnIoUnitType’. Nice to know the list is hidden in there somewhere- perhaps in a future revision they could add a hyperlink from the C++ functions to the memory map area?

Actually my current issue will be invisible to the user, but cause a difference in how something is done based on installed equipment. I date myself first by admitting that I’ve been using your products in this application since 1984- the primary code has grown quite a bit and changed since then over the course of hundreds of installations, but the basics are still the same. We do computer-based controls using Opto as our I/O structure.

The issue at present is counters- in the first products we used (B1 and B2 boards, so long ago they were one-piece with a PB16 as part of the brain), simple counters were included as part of the brain’s capability- you turn them on and they are there when you ask for the value. When we transitioned to SNAP, we started with the SNAP-ENET-S64 brains. We really don’t use counters a lot (mainly for power pulse meter monitoring), and on-board counters were the only feature that we really lost. The extra cost of the D64 didn’t make sense for us, as the counts were slower than our update speed, so I just made the program count within the computer control system, sensing off-to-on transitions in the control program. The downside is that if the control program is offline, you’re losing counts. This isn’t normally a huge issue, as the monitoring function wasn’t mission-critical to our application. When we moved to the EB series of brains, we chose the EB2 as our ‘standard’, as the extra $200 in cost per brain for the EB1 just to get counters didn’t make economic sense.

Recently a customer with several existing systems asked us to add a feature to monitor waste water from a meter using pulse counting. In his oldest system, which uses generation 1 B1 and B2 boards, this wasn’t a big deal because the programming to do counts on the B1 boards uses the on-board counters. If there was a small interruption in the program running, I wouldn’t miss counts- his water rate is also very high, and pulses come in quite quickly, possibly higher than our scan rate. On the customer’s other two locations, which have S64 or EB2 boards, this isn’t going to work- if I stick with off-board counters, which are currently built into our system, I run the very real risk of losing a few pulses here and there, and if he exits the program for any reason he’ll lose all the pulses while the system is down. The answer is to replace the brain on the board with the pulse input with an EB1, and use on-board counters, like I did on the B1 system. To do this and maintain back-compatibility in the code (so I don’t break the other 100+ running systems that have EB2 boards), I need to be able to sense what brain is there, and change the way I do counters based on the brain type. If it’s a brain capable of on-board counters, I’ll use those- if not, I’ll go with the code I’m already using.

That’s it. :slight_smile: