ShaunR

While I accept your point of order, how LabVIEW represents numerics under the hood is moot. Whenever you interact with numerics in LabVIEW as bytes or bits it is always big endian (only one or two primitives allow different representations). Whether that be writing to a file, flattening/casting, split/combine number or TCPIP/serial et. al. As a pure programmer you are correct and as an applied programmer, I don't care

Interpolation?

The first example you posted.............. There are size headers already. The flatten function adds a size for arrays and strings unless the primitive flag is FALSE. The thing that may be confusing is that the server reverses the string and therefore the byte array before sending. Not sure why they would do that but if the intent was to turn it into a little endian array of bytes then it is a bug. I don't see you catering for that in the python script and since the extraction of the msg length (4 bytes) is correct then python is expecting big endian when it unpacks bytes using struct.unpack but the numeric bytes are reversed. The second example has reversed the bytes for the length and appended (rather then prepended) it to the message. I think this is why you have said 100 is enough since it's pretty unusable if you have to receive the entire message of an unknown length in order to know it's length . If you go back to the first example. Remove the reverse string, set the "prepend size" flag to FALSE and then sort out the endianess you will be good to go. The flatten primitive even has an option for big endian, network byte order and little endian so you can match the endianess to python before you transmit (don't forget to put a note about that in your script and the LabVIEW code for 6 months time when you forget all this ) If you need to change the endianess of the length bytes then you will have to use the "Split Number" and "Join Number" functions if you are not going to cater for it in the python script. All LabVIEW numerics are big endian.

Moves like that are almost never due to technical capabilities. They are either political or the sales engineer has worked hard for a long time and negotiated some enormous discounts and concessions to break NI lock-in. Have there been any changes to the decision-making management recently? Say. An ex Siemens employee?

Ahh. That explains LVPOOP.

Maybe you should post your code so we can see the issue. Ping Example.vi

Many people use Rolfs oglib_pipe but the real solution is to come into the 21st century and stop writing CLIs.

Not really a LabVIEW thing. You can manage Windows devices using the SetupDI API and you would call them using the CLFN. If that didn't do it for you then you'd be back down in the IOCTL where there be monsters.

Pharlap is a walk in the park VxWorks was the one that made me age 100 years I actually have some source with the relevant changes but never had a device.

That's nothing to sniff at. At some point you just have to say "this is the wrong way to approach this problem". JSON isn't a high performance noSQL database - it's just a text format and one designed for a non-threaded, interpreted scripting language (so performance was never on the agenda . )

300MB/sec? If you want bigger JSON streams then the bitcoin order books are usually a few MB

I don't use any of them for this sort of thing. They introduced the JSON extension as a build option in SQLite so it just goes straight in (raw) to an SQLite database column and you can query the entries with SQL just as if it was a table. It's a far superior option (IMO) to anything in LabVIEW for retrieving including the native one. I did write a quick JSON exporter in my API to create JSON from a query as the corollary (along the lines of the existing export to CSV) but since no-one is investing in the deveopment anymore, I'm pretty "meh" about adding new features even though I have a truck-load of prototypes. (And yes. I figuratively wanted to kiss Ton when he wrote the pretty print )

I was initially manipulating the string but then you demonstrated the recursive approach with objects for encoding which was more elegant and removed all the dodgy string logic to handle the hierarchy. Once I found that classes just didn't cut it for performance (as per usual) I went back and solved the same problem with queues. The fundamental difference in my initial approach was that the retrieval type was chosen by the polymorphic instance that the developer chose (it ignored the implicit type in the JSON data). That was fast but getting a key/value table was ugly. Since all key/value pairs were strings internally the objects made it easier to get the key/value pairs into a lookup table. Pushing and popping queues were much faster and more efficient at that, though, and didn't require large amounts of contiguous memory.

Retiring? Promotion? Sabbatical? Management?(cringe)

Yes. I now use the SQLite JSON capabilities for in-application uses but I also have my own parser for Websockets and comms. The other JSON library was just too slow for streaming Websockets and the NI primitive is as much use as a chocolate fireguard because it crashes out if anything isn't quite right. (which I've raged about before). If you want to see this sort of use case then take a look at blockchain.info for the real-time transactions. I went back to my original ones that I showed in the original thread and developed those further by having a format case for each and every type and used queues for the nesting (kept the polymorphic reads the same as the original). It is acceptably slower than the native one and orders of magnitude faster than the other library on large data (much the same for small snippets) although it isn't as good with all the different encoding which it just hand-waves to a string.

Quite a few NAS boxes do this nowadays automatically with smart folders. As I prescribe to the "if it aint broke, don't fix it" school of laziness I would probably tell IT to get one or make them offer me the service and leave my software alone

Note: That is the BSD-2 Clause licence. There is also the BSD-3 Clause liicence which adds a clause disavowing the use of the providers' name for promotional and/or endorsement of derivative works.

Lots of caveats and manual optimisation (loop unrolling). Not all MS functions are suitable. Ability to meet RT deadlines you require is suspect. Risk analysis would probably yield "don't touch this with a barge pole". If push came to shove then maybe some things might be possible with the node but the heavy lifting would probably need to be offloaded to meet spec. You would probably find the program that was written for the node isn't compartmentable to be able to offload defined chunks without complete refactoring of the script code.

I used LabSQL when the DB toolkit was a paid addon. It was a lot faster.

Just be careful they don't label you a contractor then there are zero benefits to being a company apart from liability.

Yes. But what is the requirement that means it has to be under your company name? Is it that you fear if it is not then your argument to the tax office is diminished or is there a specific clause that states open source does not constitute a "product" that you own and therefore cannot be accepted? i.e. is this a speculative move or is there a definite clause that applies?

What is the criteria for the Tax exemption that requires this move? What makes this toolkit a good choice over, say, you messaging library which has little or no collaborative contributions so far?

I've no idea what you are talking about (R&D Tax credits?) so it's difficult to make a judgement but you appear to want to take sole ownership rather than be the caretaker of a community project. So I object on that basis. Am I able to claim these credits too? There is nothing in the BSD licence that says you cannot take the current software and create a derivative as long as the licence is followed.I would prefer you create a new product derived from the current.to mark a distinct change rather than an attempt a seamless absorption. In time, people will probably move to your new product in preference but I think a distinction should be made and the current project control handed over to LavaG admins. I'm not suggesting that you don;t deserve most of the credit for the library. only that a distinction is made that it is no longer the same community software in order for you to benefit..

I don't have much experience with IDL (like, none ) but IIRC the MIDL compiler can create C/C++ header files. You could try running the compiler with the /h switch then use the resulting header files with the LabVIEW DLL import wizard (Tools>Import>Shared Library) It's a long shot but may get you some of the way.

DOH! I forgot that an input to the conversion requires the codepage