Shaun Hayward

Thanks

Not sure if this is the best thread...

 

I'm looking to use the JSON implementation to manipulate STIL files (IEEE 1450).

 

Is an extension of the JSON.lvlib a good use case for this implementation?

 

The format looks like this for SPI (serial peripheral interface bus):

 

Signals {

                //My SPI Signal - Direction is Relative to Slave

                CLK      In;

                MOSI     In;

                MISO     Out;

                CS       In;

} // end

 

DCLevels SPI_Levels {

                CLK        {VIH '3.3V'; VIL '0V'; }

                MOSI      {VIH '3.3V'; VIL '0V'; }

                MISO      {VIH '0V'; VIL '0V'; VOH '2.0V'; VOL '1.8V'; }

                CS          {VIH '3.3V'; VIL '0V';}

}

 

 

Any suggestions on the best way to do this? Not using STIL is not an option.

 

Thanks!

 

I think you'll definitely need to write your own parser / serializer as STIL is definitely not JSON.

What about this .Net 4.0 library? http://sshnet.codeplex.com/

 

I use that library very successfully with our embedded devices, for both SSH console access and also for SCP-ing files. The only issue I had (at the time) was needing to recompile it for the correct CLR to match our version of LabVIEW.

+1 for NativeWindow - that property is a godsend!

Could you not just create a static dispatch VI in your parent class that gets used in the ACBR node, and that VI then simply contains a single dynamic dispatch VI - the VI you originally wanted to call from the ACBR node?

I keep meaning to make time to work on JSON but here’s an idea:

 

Instead of storing the JSON Object’s values in a Variant look-up table, store them in an array and store the index to that array in the lookup table.  That might have better performance since one may be able to do some operations in-place on the array (Variant attributes always make copies, sadly).   As an added advantage, one can output the JSON Object in the original order by using the array order.  There would be some overhead here, as you’d have to sort the names based on the indexes to match them to the array order, but this part could be easily be optional based on a boolean input (similar to “Pretty Printâ€).

 

Let me think about it some more...

 

That is an interesting idea... I would imagine that being able to work in place could definitely offer better performance for large / nested JSON objects.

 

 

<Dumb question>

The request is for values not to be sorted alphabetically.. Is the solution just not to sort? Do we, indeed, sort them? Is it part of the prettyfier rather than the encoding. Where exactly is this sorting taking place?

 

From the poking around I did, the sorting that takes place is an implicit sort when adding the JSON elements as variant attributes to a containing element. They end up getting stored alphabetically (in the variant attribute tree) so when "Get all attributes" is done in the "flattening to JSON string" VI, the objects come out in alphabetical order. The workaround I threw together kept a list of names so that instead of "get all attributes" a "foreach name, get attribute" was done (which preserved original order).

Sorry for the late reply: I thought I had thread subscription turned on but no emails came up...

 

James, your right in your assessment - this was a very simple implementation that just build a string array of names when the object tree gets built. This was mostly because I didnt want to just throw a request (ie potential work) at someone without at least offering a possible "solution".

 

Using the "Large Test Case.vi" from the source didn't seem to show much of a performance penalty (see below) but if this is a deal breaker could we look into a property for JSON Value.lvclass for "Maintain Order" that when true would build and use the array, and when false (default) would use existing alphabetical ordering?

 

I didn't add this with my first offering as the performance still seemed more than adequate (given the size and complexity of the JSON objects I'm working with and the test case timing results), and adding and handling the property would make the code noticeably more complex (e.g. making sure the flag is propagated through the object tree, what happens if the flag changes  etc).  Subclassing JSON Object also seemed like it could get pretty complex as there's seconds like "JSON Value:Unflatten.vi" that specify class type as a constant on the block diagram.

Timing results (both cases are mean of 1000 iterations):

Released code = about 19.4ms  

Modified code = about 20.7ms

 

I (personally) also like encoders/decoders that have the ability to get back the original data exactly as they tend to be easier to validate etc.

 

So overall, whilst I felt this was an acceptable modification (with IMHO, some benefits), if you guys feel that the performance difference is a killer and don't like the idea of adding a property, I can totally understand.

 

Regards,

Shaun

Siphos make some pretty nice Ethernet testing equipment: http://www.siphos.net/Products/

I made the modification I suggested to a fork of this library (https://bitbucket.org/shew82/json-api-labview/) .

 

This change, just changes JSON Object.lvclass, and I didnt touch the VIPB configuration file, etc. I also don't have LabVIEW 2011 available, so the changed code is in LabVIEW 2013. Let me know if you want me to do a pull request, etc.

Hi Guys,

I'm noticing an issue with this library and I'm not sure the best way to work around it:

 

Problem: For better or worse, the API I'm communicating with needs JSON objects to be in a correct order in addition to correctly named. i.e. {"B":1, "C":2, "A":3} is NOT equal to {"A":3,"B":1,"C":2}. However, when creating the JSON object using "Set from JSON string.vi" the order seems to be getting lost. Any subsequent calls to "Get as JSON string.vi" always seem to end with the elements getting returned in alphabetical order (as opposed to the original structure order).

 

In my example, simply calling "Set from JSON String" followed by "Get as JSON string" is causing my object of {"Alias":"string","Type":"string","Configuration":[{object}]} to be converted to {"Alias":"string","Configuration":[{object}],"Type":"string"}

 

"Configuration" and "Type" are getting swapped and this is causing the 3rd party API I'm working with to discard the object.

 

One option I've thought of (but havent tried yet) is to modify the JSON Object class to maintain an array of the element names that "JSON Object.lvclass:Flatten.vi"  uses to make sure that the variant attributes come back in the correct order. Can any of you think of a reason this would not work, or have a better idea? (I haven't poked too deep into this API yet)

 

Thanks,

Shaun

Crestron is looking for a talented individual to fill the position of Test Engineer III at our corporate headquarters in Rockleigh NJ (07647). This position will be part of our Test Framework Development team, and will develop advanced production test platforms using National Instruments’ LabVIEW, TestStand and Visual Studio C#. This role will focus heavily on creating the underlying structure for Crestron’s automated test platforms and on designing modular test systems that can be adapted to a wide variety of applications and products. The systems that you produce will be used by downstream engineering teams to develop final acceptance tests for Crestron’s products.

 

Key responsibilities:

• Create LabVIEW VIs to interface with a variety of test instrumentation, and with Crestron equipment and software
• Use MS Visual Studio to create C# code that will exercise Crestron hardware. We will provide extensive training on how to work with Crestron systems 
• Support TestStand automation of production tests
• Assist in the selection and adoption of test instrumentation
• Work closely with product designers and firmware developers during the new product development process
• Work closely with other test engineers during the test development, integration and implementation of production tests
• Other duties as assigned
  

Crestron is looking for a highly motivated, results-driven individual with exceptionally strong computer programming and technical skills. A successful candidate will have extreme proficiency with LabVIEW, TestStand and C#, Java or C++. General electrical engineering knowledge and experience with product testing in a manufacturing environment is essential.
 
Required Skills and Experience:

• Bachelor’s of Science degree in Electrical Engineering, Computer Engineering, or Computer Science; Masters preferred
• Extremely strong proficiency with NI LabVIEW, NI TestStand and C#, Java or C++. This position will rely heavily on these skills and we will focus on them during the interview
• 6 - 10 years of engineering experience with at least 4 years in a test or software engineering related role
• Comprehensive understanding of product test methodologies and techniques
• Superior written and oral communication skills; the ability to work closely with a diverse group of individuals
• A desire to be an essential part of a fast paced, innovative engineering team 
• A passion for quality and a drive for excellence
  

 

 

If your interested and able to work in New Jersey USA without requiring sponsorship, etc please send me a PM with your resume attached.

 

Regards,
Shaun

Thanks!

I was struggling to explain Notifiers to a C# developer the other day and it got me thinking... Do any of you know if there is a C# construct / class / whatever that offers the equivalent functionality of a LabVIEW Notifier?

You can change the Value from a read to a right by right clicking on the property and choosing to "Change All to Write" or "Change To Write" from the pop-up menu.

However, if your literaly just setting the value, right clicking the terminal and creating a local variable instead of the value property will create a faster setup (local variables are much faster than "Value" property nodes)

If you're on Windows, you might be able to wrap some of the .net System.Drawing.Bitmap class. Being a .net object, it has full support for network streams and actually can handle a whole range of image formats.

The main downside to the .net approach is that some of the processing elements can take longer than pure LV variants (mostly due to crossing the LabVIEW / .NET boundary). In particular, if you go this approach, don't be tempted to use nested for loops and GetPixel() - that can take a ridiculous amount of time!

So, I'm trying to access a bit of the DirectSound API from LabVIEW. This is because I have multiple sound cards on my system (with the same name) and need to identify them. The built in functionality / "Device ID" technique falls down as sometimes the device IDs can change. Our goal is to use the GUID of the device to identify the device in a more unique, and reliable way (once I have the GUID, I can to a few other tricks that work to make things friendly to my test system).

HOWEVER, when I try to create the DirectSound "DevicesCollection" object to enumerate my sound devices, I get the following error:

Any ideas?

Dammit... I spoke to soon - the build spec does get updated in the Pre-Build VI, but it only comes into affect on the NEXT build (so when I was testing it seemed to be working, as I was running it all over and over again )

I bet if I made a stand alone builder (like yours) it would all work, but trying to hook into the regular build action seems to be a failure (in this case)

...If only there were a way to get the ref to the running build spec...

Creating static and dynamic VI’s of the same code is a duplication of code. I was hoping for a better option. But I guess there is no other option in this case.

Don't forget: There is nothing stopping you putting your static VI inside your dynamic VI - at least that way your actual code is only written once.

There is a class property that you can set to enforce that child VIs unconditionally call the "Call Parent VI" node?

Or, you could create two VIs, one static and one dynamic - that way, when you want to ensure that the parent's VI always gets run, you could use the static VI?

Any idea?

You are trying to go the wrong way around: you should be using the "To More Generic Class" function

That worked great! Thanks again for the pointer... In case anyone else is interested, here's my code for use with a Pre-Build action for a Packed Library (It makes the presumption of the 1st top-level VI being the library to extract the version number from).

BuildSupportAction.zip

Thanks! That's great - I was looking into the tags, but could not see the fix/build numbers, so wasnt sure if I was in the right place (In the end, I'm presuming they were not there as those numbers are currently 0).

I'll give that a try this morning and see how I get on- thanks again!

So, I have a tricky, but theoretically simple goal... I would like to ensure that when I build packed library (or any other format of plugin / source distribution), that the build version is set to the same number of my top level library. This way, both within and outside labview I can have everything see the correct version number.

Right now, I have to remember to set bot the lvlib/lvclass version number before running my build, so I started thinking "there must be a better way". I got a chunk of the way there, using various property nodes, and a Pre-Build VI, but I seem to be missing a few pieces of the puzzle.

I have attached one of my attempts, in the hope that maybe one of you guys might be able to help me get to my goal here

(I'm also open to tackling the problem from the other side, getting the build spec version and making the lvlib match)

Shaun

Pre-Build Action (attempt 1).vi

When using a Call By Reference node there's an error in/out cluster on the node itself. Also there can be an error in/out cluster on the VI that's called. Should I use both error clusters or is the one on the node kind of superfluous? Or is there a way to get the error cluster from the node into the VI referred to by the reference node?

George

I normally merge the VI's error with the node's error (with the node's error taking priority) - after all, they both are differnt things: the node's error relates to being able to call the particular VI specified, whereas the VI's error depends on the inner workings of the VI being called.