What's the correct syntax to test the IOs on startup?

sijandi

We have a client with an NI-3100 and are using an IO to indicate the status of his back up power generator. When the generator is running it closes a contact and we display feedback on his touch panels. I programmed a BUTTON_EVENT to execute this (on a Push event) and everything works fine as long as the processor has power when the contact closes, but if the contact is already closed when the processor reboots then we don't get the feedback. The LED on the processor associated with this IO is illuminated though.

I was going to create a DATA_EVENT for when the IO comes Online, but the compiler didn't like my code so I think I'm missing something obvious. Any suggestions would be appreciated.

shane

ericmedley

I'd use a channel event.

rfletcher

I've used data online events to test IO ports when the IO Port device comes online in the past with no problems, can you post the code?

ericmedley

Even after a reboot, a channel event:on will be triggered at first. I would simply use a channel event: on to set a flag that the generator was active and a channel vent: off to set the flag to off. Then I'd use a separate routine to update feedback periodically. This would catch the many scenarios where the TP feedback could get out of sync.

sijandi

Here's the code I wrote that results in a syntax error when I compile:

DATA_EVENT[dvIO]
{
   ONLINE:
   {
       IF (ON[dvIO,1])
          { //turn on touch panel feedback
          }
       IF (OFF[dvIO,1])
          { //turn off touch panel feedback
          }
    }
}

champ

ON and OFF are assignment operators, not evaluation operators so are causing the compiler error.
Remove the ON and OFF statements like the example below.

DATA_EVENT[dvIO]
{
   ONLINE:
   {
       IF ([dvIO,1])
          { //turn on touch panel feedback
          }
       IF (![dvIO,1])
          { //turn off touch panel feedback
          }
    }
}

TonyAngelo

And if you wanted to do it the way Eric suggested:

channel_event[dvIO,1]
{
     ON:
     {
          // do stuff
     }
     OFF:
     {
          // do stuff
     }
}

This event will get triggered anytime the state of the IO changes, and will properly update on reboots.

JasonS

I have encountered this issue before, it is an actual problem with the NI detecting the state of the IO on boot up. This was with an older firmware version, so I don't know if it is still an issue. They way to determine if this is what is actually happening is to telnet into the master after boot up, and do a "device status" on the IO port. When I was experiencing this issue the channel for the IO in question would report as OFF even though the IO status LED was ON. In my case it was feedback from a secure switch that was controlled via relays, so as a work around I would sequence thru the relays that controlled the state of the switch, until I got back to the default state. Once the IO state changed to OFF and back to ON it worked normally. It only seems to occur with IOs that are on during boot up. I reported the issue to AMX but they told me they had already fixed it in the version of Device Firmware I was using. I haven't tested it on recent versions of device firmware but whenever I use a secure switch I still do the work around.

John Nagy

Jason, I think the issue is that as a BUTTON EVENT, the IO does not register if the PRESS has already commenced before the program is ready to recognize it. The PUSH comes when the port transitions from off to on, same as any "button". Like the falling tree that makes no sound, if no code is ready to hear the button push because it has occurred before the code runs, it seems like it never occurred. The alternatives suggested here actively ask the port state, so they work.

JasonS

John Nagy wrote: »

Jason, I think the issue is that as a BUTTON EVENT, the IO does not register if the PRESS has already commenced before the program is ready to recognize it. The PUSH comes when the port transitions from off to on, same as any "button". Like the falling tree that makes no sound, if no code is ready to hear the button push because it has occurred before the code runs, it seems like it never occurred. The alternatives suggested here actively ask the port state, so they work.

I understand what you are saying, but it does not invalid the point I was trying to make. At one point in Device Firmware, not sure if this is still the case, the IO indicator LED would be lit but the IO device would report the IO as being OFF, if the IO was ON during the reboot. This is why I recommend sending the "device status 5001:17:0" command via telnet, it will tell you if the LED and what the IO is reporting are out of sync. If they are out of sync, actively asking the port state will still return the wrong value.

I am not sure if this is the issue that [highlight]sijandi[/highlight] is encountering, but it is worth mentioning.

Joe Hebert

JasonS wrote: »

At one point in Device Firmware, not sure if this is still the case, the IO indicator LED would be lit but the IO device would report the IO as being OFF, if the IO was ON during the reboot.

At one point, yes.
The last changed listed for device firmware 1.20.7 is:
Fixed states of IO ports after a reboot.

JasonS

JasonS wrote: »

I reported the issue to AMX but they told me they had already fixed it in the version of Device Firmware I was using.

I have a site with 25 rooms that exhibited this behavior on 1.20.7.

Hedberg

My experience with IOs and button presses at the time of reboot are not the same as what's being reported here.

With an NI700 using firmware V3.60.453 (old, low memory NI700) and device firmware V1.30.10. if an io port is set as "LOW" and it is closed when the master is booted, both a channel event 'ON' and a button event 'PUSH' occur when the IO device comes on line. The channel "ON" occurs before the button "push".

So, what I see is that either method should work -- either a button event or a channel event. In my experience with real live systems, either method does work and has caused no problems. That may just be lucky firmware selection. That is, it may just be that on the systems we used IO ports we didn't have any of the problem firmware installed.

If the only thing being done is tracking the status of the device so that feedback can be sent to a touch panel, this can be done with one line in define_program such as:

[dvTP,FeedBackButtonNumber] = [dvIO,ChannelNumberToBeMonitored]

Joe Hebert

Hedberg wrote: »

My experience with IOs and button presses at the time of reboot are not the same as what's being reported here.

Same goes for me. I have an NI-3000 that runs my house and the firmware has to be close to maybe 10 years old or so give or take a few years. The NI master firmware is 2.32.148 and the device firmware is 1.00.118.

I have a magnetic sensor wired between my garage door and I/O port 1. When the garage door is closed the I/O port is ON and lit. Whenever CHANNEL_EVENT [dvIO,nGarageDoorInput] triggers an ON or an OFF there is a voice announcement made in the house.

The garage door is closed 99% of the time. I’ve been making several changes to the software recently (I got tired of driving away and always asking my wife, *Did I remember to close the garage door?* or *Did you see the garage door go down?* so now the system also sends me a text and an email whenever the garage door changes state) and after every reboot I always get a voice announcement, a text, and email stating that the garage door is closed. Best I can tell it never misses.

It’s not to say the problem didn’t exist (the firmware change listed implies it must have) but I’ve never seen a problem with my configuration or other jobs I’ve worked on. I guess I’ve been lucky as well…