Shaun Hayward

Thanks

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

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?

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

Alternatively, if you dont have the command line tools installed (or don't want to use them ), you cou could use TortoiseSVN's COM interface (http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev-com-interface.html)

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)