ShaunR

Here ya go. Polyfit.vi Not sure why you would want a polyfit on a straight line though.

+1. You can also run a scripting VI on it that turns autorun off if you are concerned.

You will have to figure out why you are getting 0's in the reading. One thing I will say though. Right click on the serial read and write and set them to "Synchronous". Asynchronous reading is a much more complicated use case and you will struggle with the consequences while learning.

+1

For integers you can just reconstitute as i64 regardless. That covers most of them. A note telling the dev that this is so, means they can do things after for the edge cases. Most of the time the native coercion will cover the edge cases when the dev wires them up. Same goes for Singles and Doubles as Extended by detecting the decimal point, lack of quotes and the E in the JSON string to differentiate them from integers. So you end up with only 2 numeric types. I64 Integer or extended depending on the JSON format of the number.

If the samples array is empty then you are probably getting an error before or at the Scan from String -the error out of which you have wired to the case structure. You will need to debug and figure out why that error is occurring. I would suggest you make the decoding part of your VI a sub-vi. This will enable you to check the string decoding after the serial reads in isolation to receiving a response from the instrument. In doing this, you can paste in the strings you supplied earlier and check that the correct array is updated. I have done this for you below. It fixes a couple of issues with the Channels array not being passed through the false case and indexing the array from zero when channels begin from 1. Decode.vi

Your expert is correct. You must seed the channel array with as many items as you expect to index with the index array otherwise there is nothing to index into. You can define the array constant with as many channels you are expecting or you can do the following which will enable you to arbitrarily create a number of channels of your choosing.. You seem to be struggling with basic LabVIEW structures and functions. I would suggest you read and watch some online learning materials - especially around arrays and clusters - or maybe consider a LabVIEW course.

The link in the *.sh files for an explanation of the cmd options does not work so I've posted them here FYI.

I wouldn't have passed your interview. I don't think he is saying that. He is saying that since the employees' training wasn't a cost borne by the company but by the customers, therefore they are fair game for poaching. I still disagree, of course. It's just a rationalisation of a despicable behaviour to alleviate guilt.

We've had native UTF8 for years and lots of utils can handle UTF16/32. Just can't display it very easily and none of the file controls/functions support it. It's a UI problem that NI have avoided like the plague.

Not sure where you are getting the format "Channel" and "=" from but if you are using the above command to get all readings then it clearly states the format is "CH#EZOvvvv". To save line-by-line then, once decoded, just pass a 1D array of values to the 1D array terminal of "Write to Delimited Spreadsheet" with the "Append?" set to true.

Pass a U8 array of length EFIUDS_MSG_MAX_DATA_SIZE Unions are syntactic sugar for a single piece of contiguous memory. You'll just have to figure out how to interpret the data.

SFTP is a big one. It means I don't have to implement it

I also have not really had to implement undo for a sophisticated application. I have implemented "Restore Ro Default" and limited undo for settings, configurations and such but have not been called upon for the kinds of undo required for things like drawing. I would imagine the same method could be used though. I used the SQlite Savepoints for configurations and a default table which could be copied to the main table for "Restore to Default". The latter is an example library in the SQLite Toolkit for LabVIEW. Other similar operations can also be realised like restoring the state of the UI after exiting (form position, controls etc) but that's not really what you are asking here; just an indication of the usefulness of these approaches. Addendum: There is a description of a method for Undo/Redo using SQLite triggers. Automatic Undo/Redo Using SQLite They over complicated it by doing it in an "Object Oriented" fashion but I might use something similar for the redo while keeping the savepoint method for undo.

Possibly in this case as it has searching. But we wouldn't have to write parsers if the current primitives were useful I don't know what the current status of the G toolkit is, since the last person that took over maintenance and release is no longer active on this forum. That's fair enough and I'm sure appreciated. However JSON Schema - if that's your target - isn't an edge case. Your Lineator would be the place to implement that, so I'm confused by the comment "long way to go" for a library that I think is pretty much feature complete.

Indeed. I don't know what AQ is referring to with CL (Command Line? Common Lisp?) but I have a feeling he has an eye on the library supporting JSON Schema-another IETF brain-fart which made HTML a nightmare until they ditched it and brought us XML. They have a habit of taking nice simple solutions and "formalising" them them into bloated, complicated solutions that nobody uses. I think the library is pretty much feature complete at this point-maybe some data types missing but can't think of any off the top of my head - so this sounds peculiar...unless JSON schema is your target. Remember. Many of us only use toolkits like these because NI refused to make the native JSON primitives' fit-for-purpose.

A paean to the utility of JSONText.

@Aristos Queue Off topic I know. But whatever happened to AQ Character Lineator INI Serializer/Deserializer Didn't that do JSON?

Source

Refactoring and re-architecting are slightly different things. The main difference is scope, intent and risk but how you achieve them may be similar. Refactoring is to improve maintainability, readability and complexity. This has less risk to the overall behaviour of the software and sub VI'ing will do this effortlessly. Re-architecting is to improve the logical operation of how you achieve external behaviours. It's to improve modularity, interoperability and cohesion . This is a much riskier proposition. You cannot re-architect spaghetti code without first refactoring but while you are refactoring; changes in architecture may become more obvious. For example. You can't switch from a Queue'd State Machine to an Event Driven State Machine just by sub VI'ing sections of code. So what I described was refactoring. I don't think we disagree that sub Vi'ing improves readability, however, I have also outlined how to improve maintainability and reduce complexity through code reuse - not only within the old code but leveraging the time spent to benefit current and future projects. This is a tried and tested way of making sure hideous but working code doesn't turn into beautiful, not fit for purpose, code and is an argument to justify the time spent refactoring when there is probably no longer a budget for it.

Then you are already more advanced than the average programmer. What you will see? Or how long it will take to make it right? Sub VI, sub VI, sub VI. Look for reuse. Take a very small section and make it a sub VI (only one click). Clean it up. Nibbling old code from spaghetti to sub VI's has huge benefits. Don't do it all at once. A little clean up goes a long way. Do a sub VI every week or month. I can guarantee you've rewritten the same behaviors and data manipulations many times in the past; probably even within the same application. As you create the sub VI's you will start to notice some of them are very similar. Look to see if you can make them identical. This is a heuristic way of creating code reuse. Then you can start looking for old code that you have turned into a sub VI that look similar to your current project. Your old code is a test harness for your code snippets. It's been proven to work, right? Once you have it working correctly in both old and new; fill out the documentation, icon etc if you haven't already and put comments in it. Then stick it in your special toolbox for reuse. You don't need to publish the modified old code but as you gain confidence in your toolkit, you will merge the reuse code into it. If you change the reuse code, run the old software to make sure it still works correctly. This is called Black Box Testing. Old code is very useful. It's proven code that works. Cleaning it up and sub VI'ing it will benefit your current and future projects too. You will eventually be able to spot reuse code candidates as you create new VI's - the patterns will jump out at you. You will look like you were a master from day one when other people look at your old code. Only you and your source control system will know the truth .

No. Welcome. Well. I might yell at you if you write it that way in a CLFN and wonder why it doesn't work

Yup. All Windows GDI functions have thread affinity (aka must call in the main UI thread) so it wouldn't matter if you called GetTextExtentPoint32 directly, you would still have to run it in the LabVIEW root loop.

The call is not thread safe. Don't do this.