JamesMc86

31 minutes ago, hooovahh said:

So separate projects is the solution people are using?  Man that seems like it could be a pain.  I'm going to continue having it in one project for now. 

It is a pain that I would generally avoid but my issues are that I have the same code on 2 different types of RT systems so everything is locked so that forced my hand more in this case.

I've been lurking as I have nothing to add but to say your not alone!

I have taken to using multiple projects more often than I would like. I also have fun with classes and what I presume is a compile issue, my project generally wont run interactively saying random VIs are broken. If you open them, save (maybe force recompile) it will move onto another VI is broken. Eventually it will work. I depend on remote debugging instead now.

Are you able to post this as a text file?

I always have quotes around strings using this tool without issues so they are supported and as you point out it isn't valid JSON without it. I am wondering if there are some extra characters or the types of characters that are used that cause the problem.

2015 would work for me, all my active development is currently in that or higher.

Obviously if the current version could be archived somewhere just in case that would add a bit of security

This is a little from memory but:

The trigger lines in PXI (and so I am assuming the star triggers too) are fairly dumb. You are setting the state of the line so if your system expects to trigger on a rising edge (which is quite normal for PXI systems) then you would need to pulse the trigger line to work (high-low-high). Just writing a true to it twice is just going to leave it high.

I believe the inputs are just clocked with whatever clock domain you have them on the FPGA. The clock sharing in the article appears to be referring to data acqusition clocks but this shouldn't be needed for a simple trigger.

Hey Guys,

Had a play today and hit a parsing error.

It would be really useful if the errors generated included a preview of the string it failed to parse. I did a quick mod so that it includes the first 10 chars of the string it is trying to parse.

I'd be happy to look at adding this in a fork but wanted to check there is no reason this hasn't been done before.

Cheers,

James

Wow these look great, will definately be checking them out on a project I'm working on

In some ways I like the format - The best answers filter to the top and even if someone has answered you can contribute by backing it up with a vote.

Questions on here are normally answered in quite long back and forths thought which doesn't work so well as you lose the post order and so the discussion can't be followed. I don't know if that is because of the nature of the questions in which case we shouldn't change it.

My favourite tool for launch as a service now is nssm (non-sucking service manager) - much easier than mucking about with the registry.

These functions use some encryption that is built into NI's web servers, I forget exactly what for, but I have thought I got lucky before and proven to be wrong!

What sort of encryption do you need?

Most commonly with http you would make the server support HTTPS and then LabVIEW client can support this and means your data is encrypted in flight.

Just found this and thought it was worth a post for posterity.

The FPGA timekeeper is timing source independent. It's like the backend, you give it a time and it will synchronise to it, the main benefit is it will manage servoing the time, so rather than one big step change, any difference is corrected gradually.

You then need a time source to send to this library, this is where the IRIG-B decoder would come in.

The sine wave does use some different resources for the square wave (the cordic units on the FPGAs) but these should be available on all targets.

I would check that it is set to run outside a single cycle timed loop if that option is available in case this is impacting something.

Hi,

The short answer is I don't think your loop is running as fast as you think.

On a standard LabVIEW while loop on the block diagram the loop time is the execution time of the code inside the loop. 

On a single cycle timed loop is where the loop time is equal to the clock rate, this would give you the calculations you expect.

To try and work it through, I'm unsure the execution time of the delay blocks off the top of my head but it seems possible it could run in one cycle.

Remembering that these are shift registers effective means:

1) They are not part of the calculation

2) The longest path is only one side of these

This makes the longest path (the U16 to I16 conversion should be free) 5 ticks (3 if not).

5 * 25ns = 100ns period.

100ns * 9 * 512 = 460.8uS, we are getting close.

Anyway the short version is that using standard while loops for specific timing is tricky because as soon as you change the code, you change the timing. I would do some reading around single cycle timed loops, they give you reliable timing and I think are closer to the behaviour you expect, but beware there are few gotchas in some unsupported functions and if you try and do to much the compilation will fail.

Its going to depend on how fast it needs to run but some general advice:

• Typically we don't use floating point numbers on FPGA as it takes way too much space. You will need to convert to fixed point maths.
• We avoid arrays for the same reason which makes this design tricky. You could use a FIFO to track the historical values though.
• Every time you add a sample you update the running total instead of re-summing all values each time, it would be much quicker and avoid the use of arrays.

I would have a search for a moving average, I imagine someone has done this before. There is a mean in the FPGA palettes but I don't think it does a moving average like this, it will just output a value every time it has enough samples to calculate one

On thing i would like to mention is that i try to handle my labview reusable code similar to what i've seen in Nodejs NPM and Python PIP.  I try to load as many dependencies below the project folder as possible so that i have a single dependency path for my project file.  Any of the re-usable code i generate are in separate repo and is checkout'd into a separate folder just below that main project file. I then ignore this folder in source control (GIT).  Basically i treat my git repos as libraries instead of using labview libraries to contain it all.

 

VIPM is an awesome tool and i use it a lot, but it seems to me that Labview should look as making its dependencies as modular as some of these other languages.  If you could "install" this reusable code to the project folder instead of your vi.lib or user.lib folder it would make sharing code a lot more easier.  Maybe you can do this already with VIPM and i just haven't found it.  Obviously this is problematic for how pallets are used within Labview, but i think it would be a good start.

Yes! Just Yes!

Would love to do this with VIPM in LabVIEW

The reason the spec sheet reads strangely is partly due to this being primarily aimed at AC applications.

The overcurrent protection is for 10Arms which gives you the peak value for 14.051A peak. This is rated for 1 second but remember that is at AC so the rating for the 14A instantenous is probably much shorter.

Will it survive? possibly, but I think it is certainly out of specification for the card and will reduce the life.

These cards basically work by having a small shunt resistor feeding a very low range voltage measurement. That 12mOhm resistor is the part that has to take the brunt of the current and will likely fail. If you need the fast response then you can use an external shunt resistor which you know can take the load and the NI 9238 which has a 500mV input range.

The easier option is an external transducer as mentioned above but be aware of dynamic characteristics and precision with these as they are often worse than a shunt based measurement although have the advantage of affecting the system less.

I agree if we are just talking about a single VI but if we are talking about coupling APIs then dependency inversion (not "injection", stupidly similarly named but unrelated principles) useful pattern to avoid crazy dependency loads.

All it really is is a form of abstraction layer. My understanding in LabVIEW is all it is saying is your messaging API has a child class which implements the TCP, then as you are noting, don't put this in the same libraries as this means then that the TCP messaging child is dependent on messaging, but messaging isn't dependent on the TCP child.

For cases like this having additional libraries wrapping these together just reintroduces the unnecessary linking of the and breaks these principles.

I quite like smithd's rule of thumb, (wildly paraphrasing!) if you wouldn't give them all the same icon, I wouldn't put them in a library together.

I used to use them for grouping seemingly related libraries but long given up for reasons described. It just creates an additional hard link and in many cases if already using classes doesn't add huge amount of benefits.

I would second smithd's comments regarding the problem with links between classes. I would have an interface class (or even a cluster depending on whether data manipulation is required). Obviously the important thing is that it shouldn't depend directly on either class but they both depend on it, meaning either class can load without the other.

What you start to get towards here is dependency inversion to decouple elements of code, there was a talk at the CLA summits last year that was recorded that I found to be a  good explanation of this. Believe it was the US summit and the talk was by Dmitry Sagatelyan (number 15 in Mark Ballas videos).

The argument I have seen for not escaping them is because escaping increases the size of the data, in this case necessarily.

From my point of view either could work, it just meant I had to change my code and do it properly instead of cheating!

Hi,

Thanks for the update. The escaping problem turns out to be mine!

I've been trying to compare output with that of the JSON library in Node.js. It actually only escapes the bare minimum which does not include / despite there being an escape character, so both are valid JSON, just not comparable.

Hi Guys,

A couple of issues to look at. I'm happy to look at myself if you want them in.

1. Can we rename GET (polymorphic) and SET (polymorphic) to JSON GET (polymorphic) and JSON SET (polymorphic), it would make them easier in quick drop.

2. One I came across today is that there isn't currently support for escaping strings. I remember there is something in the VI.lib extras library for it.

EDIT: Just seen reference to this in the commit history for 1.3, will check this first.

Cheers,

James

I've seen it, actually happened in my CLED exam! but I don't have a great answer for it.

It's definately a compilation issue, Generally in this scenario I've either made a tiny change to force recompilation and it's enough to get around it. Other times I've had to slowly cut my VI in half to find an offending piece of code that's doing something wierd.

Most solutions I have found have done that, used a batch file and then used files on disk to communicate between that and LabVIEW.

I started work on a build server written in LabVIEW that communicates with a Jenkins plugin over TCP. I'm hoping it can be a more robust solution but I need to get back around to reviving it later this year. This does mean getting your hands dirty with some Java as well.

I'm hoping to pick this up again in the next few months as it would be a useful tool to have and will report back if I get somewhere.

But one question remains: Is there a shell of some kind I can connect to?

Those controllers run on VxWorks. If you connect a serial cable and enable the console out you can use the terminal there but it's not like Linux.

I think there maybe a key combination to kick it off, then it almost acts like a C interpreter, you can even load and run functions from shared libraries. If you google around you will find some standard VxWorks commands documented to show things like open sockets etc.