Hi All, I am fairly new to compact field point and am attempting to setup an "on change" Digital Input event.
I have written some test code and I have had success in getting the core main functionality to work.
[For this concept code I have wired DO 1 into D1 1]
The problem that I have encountered is how to stop the "FP advise.vi" when I am finished with it.
The only example I could find was for LV 5.0 which I couldn't open.
The vi help advises:
"Caution Do not use the FP Advise (Polymorphic) VI in nonreentrant subVIs".
I think that this is a clue, unfortunately, it is a bit too subtle for me.
Thanks In advance.
No problem being new, we all had to start somewhere and you came to the right place :-). I'm a bit confused about your architecture, calling two FP Advise VI's for the same DI channel. But in general so far as terminating the FP Advise, I looked a bit more closely at the help page for this VI, noting the terminate advise input terminal, "terminate advise specifies whether to terminate the advise operation. This terminal should be set to FALSE until the final iteration of the loop containing the VI, then set to TRUE to shut down the background process". You could achieve this by wiring your same stop button boolean here.
Otherwise, if you call a FP Close VI at the end of execution, it causes the corresponding FP Advise VI to execute one last time and stop. Make sure that any error wires used as inputs to the FP Close VI aren't dependent on the FP Advise code. Using execution highlighting, you can see the FP Advise VI complete without any further value change.
Is this VI snippet below itself a subVI in a larger application? If not, both of these FP Advise VI's are running on the top level so no need to worry about reentrancy. Please let me know if you have any questions, but it seems that wiring a branch of the stop button to the terminate advise input of the FP Advise VI instead of just a false constant in the bottom loop should do the trick.
At this stage this is just a proof of concept VI.
The second FP Advise call was an attempt to cancel the the first one (a bit like swallowing a spider to catch a fly), It was just a guess.
The problem I have is that I cannot predict when the last loop is going to be called.
I am using the inputs for user interaction, When the operation has finished it is unlikely that there will be any more user inputs to allow the .VI to finish it's execution.
I had discounted FP Close because it used an FP refnum. I didn't realise it was a poly and works with the FP channels as well.
Thanks for that!
Added it to the code and got this message during deployment:.
Deploying FP Close(IO).viFP Close(IO).vi loaded with errors on the target and was closed.
LabVIEW: Failed to load shared library FPLVMgr.dll:ialv_releaseServer:C. Ensure that the library is present on the RT target. Use MAX to install NI software or FTP to transfer custom libraries to the RT target.
I have installed every possible library onto the device through MAX, Got any suggestions?
And for my next challenge, is there a way of using relative naming for the I/O ports.
I want to write portable code.
I am familiar with PC based systems and DAqMX and using property nodes to detect devices and available ports and combining them into portable code.
So something like: Localhost\cfp2220 @0\Digital Input 1.
I am finding the code and support for these functions appears to have be last updated in or before the LV7.1 Era and are now lying dusty and dormant.
I'm glad you were able to find the answer to your own next challenge! In regards to the screenshot, there is no way to gauge when the bottom loop will execute, this is an essential concept of graphical programming dataflow. You currently have nothing enforcing it to run "last". When the VI starts, all the inputs on the left side off all three loops are available, so they will all execute from the get-go. So it's great that multiple loops can run in parallel in LabVIEW, but not if it's not the behavior you want. The best way to enforce execution order is with the error wire. Check out Frequency Measurement.vi in the LabVIEW example finder (Help>>FindExamples>>HW input/output >>FieldPoint>>Advanced. See how the error wire follows through the VIs such that individual VI's can't execute until all the wires from the prior code block have completed?
I wonder if the shared library error is caused by the block of code in the lower lefthand corner. What happens if you diagram disable that three block section? Does the deployment message still occur?
As far as execution order is concered, I conceed, a rookie mistake, again this is test code.
It is a moot point since I could never test it as the FP Close is not supported by my version of labview.
No, the Class Object (Shared Library code?) have no bearing on the error codes diagram disabled or otherwise. The error goes away when I diagram disable FP Close.
In the example you suggested (Thanks for the help, I was unable to find it myself),
This example does not use the FP Close VI.
Is the sample rate important for an "On Change" mode important?
I have Hacked the FP advise.vi to include a timeout.
Find attached, I do not know enough about the .dll call for this function, i am worried about causing a memory leak by using a new "instance" each time I call the VI.
For an "On change" event if it's TRUE, the VI returns data only when the data changes. If "on change" is FALSE, the VI returns data on every poll of the data item, which is the only case where the sample rate would matter as it's the rate in milliseconds at which the VI polls the data item.
It should be fine that you "hacked the vi" to change the -1 default constant to a control. An in-between step would've been to just change the timeout to another constant value and toy with it that way to avoid a user interface call. Also, a less intrusive change would be to keep the control inside the case structure instead of outside of all the nesting, but either way should be okay. Are you still seeing the deployment message or any other problems?
Thanks for all of your insight,
Yes I still see the Deployment fault with FP Close,
In my opinion it is a bug that should go straight back to the developers, they have forgotten to include the FP Close Function when they compiled the LV10.0.1 version of the .dll for cFP.
That aside, I have become familiar and comfortable with VI's that timeout and or get status of a running process. I am presently using them in Queues, Events, Daqmx calls, VISA Serial read.
My driver architecture is built around them, it is the only way I can check for an emergency stop while the task is running. To be honest I found it strange that one wasn't included in the cFP function.
I am comfortable with my hack as it brings it into line with other LV vi's and doesn't break my architecture. The workaround is better than the broken function.
As far as implimentation is concerned:
1. This is test code, in the long term the input will be wired to an event notifier or some other logic.
2. Nesting the control in the loop, I can't figure this one out, I have had 2 different LV trainres tell me different things (it is possible that I have missed the context). All the autogenerated Class code I am working with puts all controls outside the case/loop. The fp advise follows the same philosophy. Without knowing exactly how and when LVreads the inputs and if it is more efficient to read them all is a bit of a mystery to me.
I must thank you for your help on this matter, I appreciate it.
It has made my week just a lot nicer.
I can now move onto my other problem where my Modbus Master works intermittently when I write to it programaticaly.
You are more than welcome for the help, it was nice to cover a fair amount of topics. Good luck with your application!