VI to configure FP1001 watchdog using optomux?

[bob_miller]

Hi,

I have an FP-2020 talking to a remote FP-1001 through its COM4 (RS-485) port.
The FP-2020 is running a standalone application.

I am in the process of wading through the FP-1001 manual and looking at the
confusing array of commands to configure, enable, and otherwise "diddle" with
the FP-1001 network watchdog via optimux.

I want to build a VI that is run on the FP-2020 that "snapshots" the current  state of the
FP-1001's I/O bank and stores this state as the network watchdog timeout state, sets the
network watchdog timeout value and enables the network watchdog for the FP-1001.
I will likely run this VI every so often automatically to insure that the FP-1001 never gets
unconfugured (such as swapped out or replaced with a new module).

Being the lazy bum that I am, can someone enumerate the set of optimux commands I
should run? Someone have a piece of example code that does this already (I am already
familiar with talking to the FP-1001 through optimux)?

Note that I do *not* wish to configure/enable the FP-1001's watchdog through MAX; I will
not even normally have access to this module except through the FP-2020's COM4 port.

Thanks!!!

Bob

[Travis G.]

Hey Bob,

I've done a search of the example programs on the NI Example Code Library, but haven't found anything that exactly matches what your trying to do.  The closest thing I found was the following example, which may help as a loose framework for your application:

Example Program: Using FP-20xx to Publish Data from FP Modules Connected to its Serial Port 

If anyone's interested in taking this on, the optomux commands for communicating to an FP-1001 can be found in the FP-1000/1001 Programmer Reference Manual.  

Travis G.
Applications Engineering
National Instruments
www.ni.com/support

[bob_miller]

Hi Travis,

I have already been to that example for other aspects of my system's
design. I have seen some older discussione on the topic but nothing
as yet paint-by-number.

I have coded up something which doesn't yet work; I plan to spend
some time this evening troubleshooting it and will report back tomorrow.
If I get it to work, maybe I can post the vi, otherwise I may need help
fixing it

Bob

[Graziano]

Hi Bob,
   can you clarify in which sense it doesn't work? I mean, are you getting some error message, or the application doesn't perform as you expected?

   Can you post your VI (for LV 7, if possible...), so that I can test it? I'm developing too an application for embedding it in a cFP-2020, that communicates over RS485 and Optomux with multiple FP-1001.

   Let me know! Have a nice day!

graziano

[bob_miller]

I dug down in the vi last night to isolate what isn't yet working and it
turns out I'm getting timeout errors on the optomux commands
!Q (SetWatchdogDelay), !V (StoreWatchdogDelay) and !l (StoreWatchdogEnable),
and possibly !X and !W. other optomux commands in the vi, e.g.
!R (SetDiscreteWatchdogData) work fine. I tries increasing the timeout delay
(to 2 seconds) and that didn't help.

 ***I just found the error as I was posting the "code" below: baud rate/timeout
      cluster wired to "error in" port of FPOptoOpen.vi instead of "VISA Parameters"***

Debugging is slow and somewhat painful since I am communicating to the
fieldpoint through a dial-up soda-straw and I must shut down its other
mission-critical tasks (its running a small public drinking water plant) to
debug "in vitro".

I can't get the VI to this machine to post it directly at the moment, but I can
enumerate the gist of it here. The intent is to incrementally load a desired  "fail-safe" set
of channel data into the watchdog data and the power-on default data:

1) Open the port with FPOptoOpen.vi (COM4,  baud=115200, timeout=2 sec)
2)  SetWatchdogDelay.vi (COM4, moduleAddress=1,delay=1000=10 sec)
3) StoreWatchdogDelay.vi (COM4, moduleAddress=1,delay=1000=10 sec)

4) for each discrete channel I want to change {

      (get channelMask, failSafeData for this channel -- how is not important to the discussion)
          if failSafeData=1 then dataMask=channelMask else dataMask=16'b0

      WriteDiscreteWithStatus.vi (COM4, moduleAddress, positions=channelMask, Data=dataMask)  << not sure I need to do this
      SetDiscreteWatchdogData.vi(COM4, moduleAddress, positions=channelMask, Data=dataMask)
      StoreDiscreteWatchdogData.vi(COM4, moduleAddress, positions=channelMask, Data=dataMask)
      StoreDiscrete.vi(COM4, moduleAddress, positions=channelMask, Data=dataMask)

      SetWatchdogStatus.vi (COM4, moduleAddress, positions=channelMask, EnableDisableMask=channelMask)
      StoreWatchdogDataStatus.vi (COM4, moduleAddress, positions=channelMask, EnableDisableMask=channelMask)
      }

5) StoreWatchdogEnable.vi (COM4, moduleAddress, delay=1000=10 sec)  << I was surprised to have to wire the delay here!
6)  UseSnapshot.vi(COM4, moduleAddress, snapshot="User Defined Settings")
7) StoreSnapshot.vi(COM4, moduleAddress)

8) FPOptoClose.vi(COM4)


Have I got this right? Is there extra/missing stuff or stuff done in the wrong order or a better/easier way? I will test this
again (with the miswired port fixed) as soon as I can...

BTW, these channels are in a FP-TB-10 module hanging on the FP-1001. The baud rate, timeout, module address
and channel masks I am using are known to work correctly for optomux read and write discrete VIs.

Bob




      

[bob_miller]

I stand corrected; the FPOptoOpen "VISA Parameters" port was properly wired (wire route had been pushed
ambiguously under the VI).

So I still have the problem of a timeout error on the VIs mentioned above.

[bob_miller]

Here is the LV7.1 VI. Still not working (timeout errors on the !Q, et. al. VIs).
If the error chain is uncoupled the VIs within the case structure all
execute successfully (no error)

Bob

[Graziano]

Hi Bob,
   since  I didn't actually read all your post (..sorry!),  I only gave a look a t your VI.  In FP-1000/1001 Programmer Reference Manual, I searched for the description of  Set Watchdog Delay (!Q).  It's page 5-55, in the "description" field, you'll find "you should set  the watchdog data  before you issue this command".  Maybe it refers to Set Discrete Watchdog Data (!R) or Set 16-bit Watchdog data (!S).  Just try using them, and let me know.....
  
    More, the first Optomux command to be sent to all FieldPoint Module should be "Powwer up clear", A (N.B, A, not A!)

   Hope it helps... have a nice day!

graziano

[bob_miller]

Hi Graziano,

I have gotten the timeout problem isolated; it is apparently
a hardware problem, most likely a delay setting issue on one of
the RS-485 isolator/repeaters which are between the FP2020
and the remote FP-1001. Connecting directly to the FP-1001 with
my RS-485-equipped notebook and running the vi from windows
had no such problem.

Thanks for the pointer to the note about command ordering and
to the "power up clear" command. The latter is probably not
the issue, since the FP-1001 is normally not being power-cycled
prior to executing the VI, but may become one (more on that later)

I actually got the network watchdog configuration working last night.
It turns out the !Q, !X and !Y commands, at least, must be addressed
to the interface's address, not the I/O module. Its not always clear
from the documentation which is appropriate. My FP-TB-10's
module address is 1, the FP-1001 driving it is 0.  Addressing the
three mentioned commands to address=1 returned an "unimplemented
command" error which tipped me off.

But once I changed these addresses, ran the VI, and power-cycled the
FP-1001, the network watchdog started behaving. The fact that I had
to power-cycle the interface suggests I'm still not doing everything
right, but i'm getting closer; its better to have to power-cycle to effect the
configuration that to have it evaporate when I do so!!

Current state of the vi attached. If anyone out there can clarify which
optimux commands should be addressed to which module and provide
a definitive execution order in a corrected vi,, I think both Graziano and
I would be your lifelong fans....

Bob

[bob_miller]

I wrote:

>Thanks for the pointer to the note about command ordering and
>to the "power up clear" command. The latter is probably not
>the issue, since the FP-1001 is normally not being power-cycled
>prior to executing the VI, but may become one (more on that later)

Here's the 'later": I noticed that when the fp-1001 goes into the
watchdog state the first command sent to it afterward fails, just like
at poweron.  This is not an issue for my application, but may be for
others -- let the wireworker beware...

Bob