JamesMc86

You need to run this as a windows service to achieve this.

There is no native way to do this but I have seen people use other tools that allow this. I can't remember the name but if you search run any exe as a service I imagine you would find something. What happens is that EXE runs as a service and then launches your EXE based on a registry key.

Tim_S's use case is an interesting one I have seen on FPGA several times. I did put in an idea exchange for a loop unrolling system for FPGA, you can't use a for loop because it is forbidden in an SCTL (and would take too long) but semantically it is so much easier!

This is the link:  http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Allow-Parallel-For-Loops-on-FPGA/idi-p/1599930 In that case I was thinking the parallel loop syntax could be used.

It is a little unclear what you need. The state diagram you attached appears to just correspond to the different methods in the class. What exactly are you struggling with?

If I understand correctly you just need driver versions from that system?

Easiest thing is to generate a MAX report (File>>Create Report). This will include a list of driver versions, I'd just go for the standard technical support report.

Cheers,

James

Many of the early error codes share a code between LabViEW and GPIB. Written above or below this error should be the LabVIEW error. What is the error code?

Not had a chance to use in anger yet but the new experience for web services looks like a massive improvement. Adding static pages previously was a but cludgy but this looks to be a huge improvement.

You are correct. NI have added path labels so that it still looks like windows/pharlap. When you use the file path types on VxWorks LabVIEW converts under the hood so c:foo.bar becomes /c/foo.bar. If you put the windows style paths directly in as a string it wouldn't work.

I am surprised that the drive letters are case sensitive as well considering this conversion is happening. May have to have a play.

Do you mean LV2011?  This is the version the code was originally in. I will get that done.

Cheers,

James

Hi,

Thought I had already posted back, sorry!

The root cause is that the OpenG Scan From String puts the enum string through a scan from string with %s which removes anything after a space so this bug specifically effects enum strings with spaces.

A customer of mine has also had issues with strings in clusters. In JSON Scalar.lvclass:Variant Decode.vi it assumes all array elements are the same size. In the case of an array of strings or an array of clusters with strings this is not the case. I guess this comes back to your discussions about ragged 2d arrays as well. You can see the issue in the attached VI. He has managed to write a fix for this that we can share as well in whatever format is easiest.

If processing is the concern then the main issue is going to be background processes. The good news is I wouldn't expect much dependency here. I still don't know if it will run without X but going for a minimal window manager will be a good start. Then removing any continuous running processes in the background (use top to see what is running). I don't imagine there are many/any that are required.

EDIT: Just tested, definitely need X running.

I would try killing x to see whatit does. LabVIEW still doesn't have a concept of a console only app even on Linux. Best case it still runs without issue but I wonder whether it will throw an issue. In terms of sw requirements, as a few people have said you need the runtime engine. I am not aware of any dependency listings beyond the 3 distros NI officially support. That said I have found it to run without issue on manjaro so there's nothing too specific.

Hi Alex,I've never used it this way but I believe each loop should be able to open their own reference to the FPGA as long as they are all using the same bitfile/VI. Cheers,James

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

I know NSVs had a whole lot of problems in the early days. It usually takes a few years to work out the bugs with any NI technology as far as I have noticed. Hopefully they are ok now...

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.

+1 for a good question.

 

Playing devil's advocate, I appreciate LVClass, LVLib, and LVProj underlying representations as XML -- source code control infrastructure (including diff/merge) generally just work way better with text

Perhaps 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.

Have you discovered any problems with defining internal FIFOs on the block diagram as opposed to in the project? It sounds like a very useful paradigm, don't have a use for it right now but can definitely imagine using it in the future. 

I get the advantage of working with both DVR and Objects. However I am still very sceptical about the use of the in place structure to read the object directly in the main VI. I see the DVR Based Objects a really safe way to work with class while making sure they are initialized and to avoid data copies. Working with In Place on the main VI theoriticaly gives me the right to remove an initialized object from a reference and replace it with another object from the class or, even worse, a non initialized object.

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.

However it is advised not to allow to use the In Place Stucture outside of the class method 

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.

 The "it begin with v" lead to think that the aVarID could be a string

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