JamesMc86

Your use of the references sounds complicated (although doesn't explain the latest error). If you have multiple items needing to access the FPGA each should open its own reference. If you attempt to run the FPGA and it already is you will just get a warning generated. Then each element should close its reference. The default behaviour is if it is the last reference open then it will reset the FPGA, you can change this with a right-click. Your original issue sounds like an FPGA VI that either connection has failed (but this should throw an error) or an FPGA that has been reset. Reset is not the same as load so a reset would mean the FPGA is not running in your setup but it is perfectly valid to interact with FPGA when it is not running hence no error. I hope that explains it. Open references shouldn't cause deployment issues, only run time issues. There should be an error message earlier in the window somewhere indicating the issue. Sounds like some sort of conflict is occurring. Cheers, James

There is certainly some truth to this, many of the new guys in support haven't heard of "tagsrv.exe has stopped responding"!

Hi, Your hunch is potentially correct. There is a certain amount of overhead associated with each shared variable (time stamp, FIFO if selected) and so grouping elements can help reduce the processor associated with it. Don't forget though this means larger memory usage everywhere you access it (as you read the whole cluster), increases network usage (as all data is sent one one update) and may force some nice race condition risky read-modify-write actions if you have to update a single element so it isn't without cost! They shouldn't bee too large.

IF the merge didn't corrupt them! :-PPerhaps if you could have the class hierarchy view with some fast edit ability. As Darin said maybe because I started with LV I don't fully follow how you can get to code faster though.

I'm intrigued, how do you see G representing classes? For me as a data flow language it isn't so good as a structure definition. We use .ctl for data structures which is used for classes and obviously VIs for methods. The XML part leverages the existing (although not by much) library system. Having said that I have heard criticism for OO that it takes too much away from the diagram and I think more that can be kept as G the better, or maybe some similar graphical representation.

The main issue I see is your resource definition is spread about rather than being in one place so if you run into resource issues it is harder to get a picture of what is going on. That said this technique is also great for reusable code. Take a look at the VST sample projects, they make extensive use of this for reusable code modules under FPGA.

I agree, in cases where a class must have initialisation forced this is a good method to protect it and there certainly are use cases for it. But for me LabVIEW is a dataflow language and OO doesn't have to break that. Reference based APIs are great where you have to guarantee initialisation and protect access. There are also somethings that may suit it well, take a look at the extensible session framework (ESF) on ni.com for this. I also agree if you are using a reference based API it makes sense to force the IPE to not be allowed outside. However if this is not absolutely require by the object then I see no reason to use it. It them becomes a matter for the architectural design rather than the object design how to move that data around and I believe you should provide a by value (dataflow compliant) API to fit with LabVIEWs cases and it is up to the developer how to use it. My argument is not that it is a bad idea, but that there are better solutions for other cases.

I would suggest it is not as black and white as that. If you are trying to guarantee the correct use of the object in a reference design that is correct. However I have used designs where I still make the methods take the object directly and the application is in charge of dealing with the DVRs. There are a few advantages: The class is more reusable, it can be used by value or by reference. DVR is a form of communication, the application architecture should and can dictate the communication method, not the library. You can decide what functions are 'atomic operations' i.e. you have methods A, B, C. If each method passes a reference to another and you have two loops you could have the execution order A1,A2,B1,B2,C1,C3 or any other combination. If the methods pass objects you can wrap all 3 inside a in place element to guarantee A1,B1,C1,A2,B2,C2 or 2 then 1.

There is http://www.ni.com/white-paper/3198/en which mentions what triggers the events although I suspect you were looking for more specifics than this. This would be a great thing for the wiki if something does get nailed down.

I expect it is an enum somewhere in the header, certainly worth checking. Can you do something to force it to return an error e.g. Intentionally give an invalid variable so it returns non zero? Just to confirm there is life on the otherside! Also read the error terminals on the node in LabVIEW.

Hi, Hoovah's comment isn't totally accurate. On a multiplexing card if you request 1000 channels on 2 channels it doesn't do 1000 chn1 then 1000 chn2. Rather it takes one from each at a time so chn1 - chn2 - chn1 - chn2 ...... This does still cause a small phase error though. The good thing is the card you have is a simultaneous card so it truly can acquire on both without phase error. Good luck!

This looks like a general fPGA compile issue. You can confirm this by creating a really basic VI and seeing if it has the same issue. Has this machine ever compiled successfully?

Hey Guys, Had an issue with JSON to Variant where types mismatch because of no enum support so variant to data threw an error. Though it easiest to keep seperate so there is a patch attached. I see it already encodes the enums as string anway so I used the OpenG Variant tools to use this and set the variant value as a string. EDIT: Won't let me upload a patch, shall I push it into the bitbucket repo or fork first? Cheers, James

What does it say when you try and deploy?If it was incompatible I would expect the build to fail rather than the deploy so I think it should be possible, but something is obviously in the way

I would suggest the 24/7 running is the requirement for real time. The OS (and associated tools) are designed for that type of reliability. What it doesn't do is make your code run any faster so as you say the performance suggested should be possible on Windows or Real Time.

I would suggest an ideas exchange to add the internal structure to the exe preview and you would have my kudos! In 2009 you apparently could use the openG zip tools but that doesn't seem to work any more. That was on Jim Krings blog that showed that technique. I haven't found another one yet unless someone would like to surprise me

Thats it, same solution but less code you have to write. At the minute the code is just 4 parallel for loops accessing the FGV as fast as possible. What this does mean compared to a real application is that there is no downtime at all and so you probably would not see it as being this significant without a lot of usage. But this is always an concern with any non-reentrant code. I was called in on a system once that talked fine to 2 cRIOs but had double digit second latency when trying to talk to 14. It turned out to be a non-reentrant VI at the center of the comms protocol that all of them where fighting over. For this reason I always avoid polling FGVs in high performance loops now.

That I haven't dug into figures on. The overhead of the SVE will increase as each read/write it has to timestamp etc. this could also be dependent on the number of clients connected. As I say in this case I'm assuming this is happening anyway as you are using it for network communications. For the individual read/writes I expect this will have some impact on those without RT FIFOs, with RT FIFO your code is isolated from the SVE load, that is what makes it deterministic. I haven't seen the implementation but I guess it will be similar to using a single element queue. I think the read will have no impact on the engine as we will only be touching the RT FIFO. The write will but will be handled asynchronously by the engine.

In this case the FGV is only a global variable as well though, so there is no advantage there. I wanted to check my figures on some of this so I did some benchmarking. The other element I failed to mention before is enabling the RT FIFO will sort out a lot of performance issues. The results I saw (on my laptop). (times in ms) Variable Access Time (1) Access Time (4 in parallel) FGV 0.46 6.26 NSV 8.34 16.9 NSV + RT FIFO 0.078 0.315 So FGV vs NSV, the FGV is much faster (as expected), what always worries me with FGVs is I have seen them kill code performance when used heavily in parallel hence the comparison there. In this case though they are still better to NSV. The RT FIFO though makes the implementation deterministic and much higher performance. It isn't going to reduce the latency of the updates to and from the SVE, but for raw access time it is much faster. I am not suggesting that you should drop all FGV for NSV + RT FIFO. The added overhead of running the variable engine comes into play and developers preferences, but for this use case there is no need for adding code for performance improvements. I have attached the code. Thrown together a bit quick as I should be doing busy work now, but I think the results stand. FGV vs NSV.zip

Yes, I appeared to be in a time warp when I wrote that and was referring to it being more robust than adding a delay. Personally in this case I don't see the case for increasing complexity with the FGV. Yes polling the NSV is less efficient but this is only occurring on start up before the application runs. With an FGV you now have to keep the two in synchronisation and there is a possibility that your FGV can hold a different value than the NSV which would be a nightmare to track down. I'm not saying it will with the current implementation described but it can if not used in the correct manner. And I don't see a great benefit other than a slight performance improvement (which will only really show if you are polling it fast).

What is the card? The manufacturer may provide a driver which makes things easier. Or you can use NI VISA which is a general instrument driver and can talk to some VME devices, see http://digital.ni.com/public.nsf/allkb/4E49DE1C52039B7186256ACE0044B556

A more robust solution shown in some of the courses is to add a loop after initialisation to read the values in a loop until they match the initial value to avoid the dependence on picking a delay value

The PXI systems leverage commercial processors so they are not necessarily any more powerful than a desktop. From a hardware perspective you just have to consider quality. Your average desktop PC is designed to run < 8 hrs a day for a few years but the PXI systems are designed for 24/7 running. They may also feature additional real time elements such as hardware watchdogs and lower jitter setups. Not to say there aren't also PCs that can do that but not your standard consumer grade PC. If that is not required for your application I expect you will be fine.