FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

Avoiding IAK file/FP Read debacles with Datasocket reads

Hi Folks,

 

I should first say that this isn't intended as a rant session, more of an open discussion on how to avoid some common IAK file pitfalls and possible alternatives. Currently I'm importing my IAK file and using FP Read / FP Write routines.

 

Here's my problem: I have over a dozen cFP-2010 comissioned that are running independantly across a few areas, performing the same operations. For sake of argument let's say they all have identical hardware/software. Each is tied to a dedicated workstation on a peer-peer network.

 

Right now I am spending the majority of my debug time messing with the IAK and project. There is nothing within the IAK file that changes-channel 'names' stay the same. However for each new deployment I have to open the last-used IAK, link it to the cFP/download names, save, import into my project, and build. I can't just take a common build and apply it to each, and it's becoming a problem to service as well.

 

SO, I'm looking for suggestions on how to move away from this approach. I would like to put all the cFP's on the network, be able to 'browse' for available targets, and chose which to connect to from the workstation. I've found a VI to search for available cFP's on the subnet (via broadcast), but I'm limited to Datasocket reads/writes. I can't imagine creating an IAK file for each... every workstation would need update then if one changed.

 

Is anyone else using the Datasocket functions in place of FieldPoint Read/Write for similar reasons? If so what protocol (there are a slew, lookout, psp, fieldpoint) did you use for your reads/writes? How has performance compared?

 

Thoughts?

 

Jamie

 

 

v2009 devel. w/RT
0 Kudos
Message 1 of 4
(5,887 Views)
Make sure all racks are in your project. Get the Rack IP address by using the "string to ip". Then convert back using IP to string and ensure you connect a true constant to the dot notation. Connect the string output of the IP to string to your case structure.  For each IP address in your project create a cluster of Field Point IO Points for each CPU and IO Slot. Then you can unbundle each name when you need to access the Field Point IO. Use the Field point VIs to access the IO. Also if you keep all folders under my computer for the project you need to only add the vi file to each target. This simplifies the builds for exe's and file management.
0 Kudos
Message 2 of 4
(5,773 Views)
Make sure all racks are in your project. Get the Rack IP address by using the "string to ip". Then convert back using IP to string and ensure you connect a true constant to the dot notation. Connect the string output of the IP to string to your case structure.  For each IP address in your project create a cluster of Field Point IO Points for each CPU and IO Slot. Then you can unbundle each name when you need to access the Field Point IO. Use the Field point VIs to access the IO. Also if you keep all folders under my computer for the project you need to only add the vi file to each target. This simplifies the builds for exe's and file management.
0 Kudos
Message 2 of 4
(5,773 Views)

1 - Add all the Field point targets to your project. 

2- At startup of your main vi. Create a case structure and use the IP address (as string) for each rack based on the 1 - Add IP address. Place a cluster of field point IO constants in each case. To Get the Real Time CFP  IP address use the String To IP Function . Leave the string unwired and connect the IP (U32) to the IP To String Function. Wire dot notation as true to  Convert back to a string so you can use the IP address as the case selector. Create a cluster for the fieldpoint IO for the CPU, each slot and any attributes you may need. You can then use unbundle by name and the field point read VIs to read/write to the IO. As your program requires.

3- Also add the main folder to my computer that has all the files for the project using auto poulate . Under each target add only the VI that will run on the Field Point target. This simplifies file management and will allow you to have only 1 main vi. that is the same for all targets. Any Config. parameters or other differences can be saved as a file on the individual field point CPU drive.

0 Kudos
Message 4 of 4
(5,769 Views)