From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

Transitioning From Compact FieldPoint to CompactRIO

This is in regards to the White Paper with the same name as this Post Subject: http://www.ni.com/white-paper/52272/en/

 

I wanted to respond with feedback right on the White Paper, but it seems like that option is not available.

 

One use case I do not see addressed by this White Paper is the capability of the cFP-1804/1808 to natively work with the Extended Optomux commands when using the serial connection over a modem.  Yes, yes, I KNOW it is antiquated, but we still have customers that DEMAND dial-up modem communication capability.


The great thing we found was the native support of the Extended Optomux commands on the cFP-1804/1808. 

Discussion of Optomux commands with cFP-180X White Paper: http://digital.ni.com/public.nsf/allkb/005DCF36D1C88E7586256CBD00634E92

 

What is the recommendation on switching to cRIO in replacement of cFP-180X devices that are using the native Extended Optomux commands?

 

Would we have to use a controller with a built-in Console Out DB9 or go with a NI-9870 and write our own Optomux response/handshaking code?

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 1 of 8
(9,476 Views)

Hi Ryan,

You are right, only the field point devices directly support the Optomux driver/API. The Optomux protocol might be considered as old and slow compared to more recent serial protocols and is usually not recommend for new designs. I understand that there will be few customers that would still require this kind of support for their current systems. I haven’t used really much this protocol before, but I understand that the FieldPoint Optomux VIs are just VISA VIs with the corresponding protocol communication and there is nothing strictly related to the FP or cFP itself. As we can still deploy VISA and Serial VIs onto a cRIO, I think that customers with previous experience working with Optomux might be able to use the same VIs as a starting point.

 

Regards,

AGJ

0 Kudos
Message 2 of 8
(9,450 Views)

The system doesn't have VIs written for it, it just natively supports the Optomux commands based on the IAK file loaded - the only programming we have to do is configure the cards and types of channels and the system automatically responds to Optomux communication.  This is a great feature.

 

I guess we'll just have to write some code to replace this functionality.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 3 of 8
(9,445 Views)

I also wanted to talk about this transition. At my place of work, we have a several cFP units in the field that are collecting data from over 500 sensors. If we do get a cRIO master controller, we will be able to add it as a Real-Time Device in its project folder? Meaning, we would like to use the cRIO Controller as a master which will then talk to the cFP Slaves within the network.

Starting from LV2016...will we be able to talk to any cFP modules at all?

 

 

0 Kudos
Message 4 of 8
(8,291 Views)

 

 

http://download.ni.com/support/softlib//fieldpoint/15.0/FieldPointReadme.html

 

After LabVIEW 2015 SP1, you can't use cFP hardware at all.

0 Kudos
Message 5 of 8
(8,283 Views)

I missed your first reply.

 

Yes our hand is being forced.  I have seen nothing from NI regarding possible options that will support Extended Optomux natively like the FP1000 did and then the cFP-180x units.

 

I'm either going to do this with an sbRIO or equivalent or transition to non-NI hardware, as I tihnk OPTO-22 still sells Optomux units.

 

Ryan

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 6 of 8
(7,596 Views)

NI no longer makes extension IO products that communicate natively over serial (232 or 485).  If you want a system that communicates over serial you could "build your own" with a real-time controller.  Basically use scan-mode to automatically detect and read from the IO modules, then map that IO into an Optomux data set.  Finally create a serial responder that speaks optomux and exposes the Optomux data set. 

 

Not trivial but not particularly unusual either.  However it is a work to have to do the programming instead of getting something native and out-of-the-box. 

 

You may want to check out the reference architecture called "Tag Bus Data Framework".  I know it has been used to create similar systems (only instead of Optomux they were using Modbus). 

https://decibel.ni.com/content/docs/DOC-41721

0 Kudos
Message 7 of 8
(7,589 Views)

That is about what I expected.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 8 of 8
(7,563 Views)