01-19-2015 04:08 PM - last edited on 07-15-2024 07:16 PM by Content Cleaner
This is in regards to the White Paper with the same name as this Post Subject: https://www.ni.com/en/support/documentation/supplemental/14/transitioning-from-compact-fieldpoint-to...
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.
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?
01-20-2015 11:03 AM
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
01-20-2015 02:52 PM
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.
10-22-2015 10:12 PM
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?
10-23-2015 07:57 AM - last edited on 07-15-2024 07:17 PM by Content Cleaner
https://download.ni.com/support/softlib/fieldpoint/15.0/FieldPointReadme.html
After LabVIEW 2015 SP1, you can't use cFP hardware at all.
02-10-2016 01:18 PM
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
02-10-2016 03:59 PM - last edited on 07-15-2024 07:17 PM by Content Cleaner
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://forums.ni.com/t5/Archive-TKB/Introduction-to-the-Tag-Bus-Data-Framework/ta-p/3545012
02-11-2016 01:00 PM
That is about what I expected.