JamesMc86

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

You sure you need RT? Don't over complicate things.

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.

My question back at you is how do you do you know where in the EXE your VIs are so you can open a reference to them in the Launcher?  Through trial and error I noticed that the path to the file within the EXE was the same as it was on disk from the project file to the Actor Core.  I wasn't sure if this was always true, and I wasn't sure where files that aren't relative to the project file are stored.  In source I have this structure.

 

C:ProjectsExample.lvproj

C:ProjectsActor 1Actor Core.vi

 

In the EXE it appears to be this

 

<dir>My Example Program.exe

<dir>My Example Program.exeActor 1Actor Core.vi

 

What about files not relative to the project like vi.lib files?  Where are they stored in the EXE and are they subject to change?

 

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 

So basically the NSV + RT FIFO is more or less doing what the FGV solution would be doing by maintaining a local copy that gets written to the network when it changes but only polling the internal copy normally?

 

Thats it, same solution but less code you have to write.

 

 

Will have to checkout the performance test VIs you posted. The parallel access numbers you posted look very much like you somehow forcefully sequentialized access to those VIs in order to create out of sequence access collisions. Otherwise I can't see why accessing the FGV in 4 places should suddenly take about 15 times as long.

 

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

I would dispute the "more" in more robust in respect to an FGV/Action Engine. It's possibly equally robust at the cost of querying a NSV repeatedly, which is certainly a more resource intensive operation than querying an FGV with a shift register, even if the NSV would be deployed and hosted on the cRIO.It would be unavoidable if someone else on the network could also write to the NSV but in the case where it is clearly published by the cRIO only, there is no advantage at all in using only an NSV alone other than not having to write a small VI, but that is a one time cost.

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.

No I ask, I haven't seen these before and you have given no description

What do they allow you to do?

Maybe for efficiency you can use both. First look for some common causes e.g. Floating point maths on FPGA which will rule out most things but it would be difficult to catch everything (for FPGA I bet this could catch 99% between using floating point, using non fixed arrays and not using the call library node.). Then do the test opening it on the target, if it is not broken it is compatible, if it is broken you can flag that file as inconclusive and highlight the VI which is broken. The harder one is actually RT I think because there are not many specific functions that make it broken under RT, it is more of a code style that needs to be considered. in fact the only things I can think of right now is if you are calling a dll and need a .out for VxWorks and if you are using front panel property nodes (but these won't break the VI, they just don't function when built) so this is pretty tough. If I was approaching this I would be tempted to make VI analyser tests for common compatibility issues to make it easy to run. You may not catch everything, but you can rule out a lot.

Hey Rolfk,My comment wasn't intended like that. That is a good recommendation, I was just building on it.

How/Why would a image be invalid?  If the reference could be invalid then Rolfk's response is a good start.  

 

There is are image info function that gives you the size and the type (RGB, U8 grayscale etc.) if that is the issue. (IMAQ GetImageInfo is the function).

If image content is the issue then you get a little harder, but guessing it will be one of the first two if the functions throw errors.

Hey,

 

I replicated the issue and I think it is a bug as it works fine using flatten/unflatten directly or in a cluster. I filed a CAR with R&D under ID 398196

 

Cheers,

James

The issue is actually not related to OOP. The error I see is related to the references within the object. It is illegal to use these on a shift register as it allows the potential for it to be changed but its value must be resolved at compile time.

 

If you create a shift register then wire a reference too it then it will normally break the VI immediately. Obviously an issue here is that the compiler doesn't resolve this in an object until code generation, it would be useful if you can specify these as invariant somehow, possibly the ideas exchange as it is intended behaviour, but it does limit what the objects can do.

 

Cheers,

James

What is the source of the files? I have not come across them before. Even if no-one has existing code for them, if the structure is published it should be possible to write a parser in LabVIEW using the binary or ASCII file palette.

I hate to be negative but I suspect this is not possible. My reasoning is that g code is g code. It only breaks once you try and compile it for a particular target which requires opening it in the correct context. I guess the defining characteristic is that the unsupported functions could mostly be summarised in a few rules. E.g. Anything using a dbl data type can't run on FPGA, I bet using scripting you could rule most VIs out of fpga execution pretty quickly. RT is harder as the differences are more subtle. I suspect this may all end up being slower though. Cheers,James

Many people I know actually still run LabVIEW for Windows in parallels instead of transitioning. The main benefit being that most/possibly all tool kits don't support LabVIEW for Mac so you are limited to core functionality. This maybe fine for you but wanted to make you aware you maybe able to avoid this.

The flip side is I have never seen anything to say we officially support this configuration but I have seen many people using it successfully (including NI staff).

Hi Erik,Thanks for sharing your experience. It is interesting to hear about Git as I reached a similar conclusion. The windows clients all had some holes in them and I got to the point where without a clear benefit to the technology, mercurial was simply easier to install, configure and use for Windows & LabVIEW.Cheers,James

Hi Flinstone,

 

The cause does appear to be a bug, what version of LabVIEW are you on? I found a CAR (128114) which appears to be the problem where the bit file is storing an absolute path to the type def instead of a relative path.

 

Unfortunately this would either mean upgrading to 2012 or keeping the disk hierarchy in the same location on both machines. I guess a third option would be to disconnect the type definitions for the final build.

 

Cheers,

James

MCornwall is right (and has some great links). The X Series do have some additional timing engines now vs the older cards but because they are still typically multiplexed cards the ADC is already in use and cannot be used twice.

 

Cheers,
James

Hi,

 

You should use the open reference in the same way. LabVIEW has some check that the running bitfile matches what the code expects (I am not sure exactly how but I think there is a checksum involved). The one thing to be aware of that if LabVIEW tries to run the VI again and it is already running it will spit out a warning.

 

Cheers,

James

Your understanding about structures is correct so something else is at play. How do you know about this update? If it is from probes is the CPU usage high? I have seen this cause probes to report some strange things from RT targets. Alternatively a code example would certainly help!