Antoine Chalons

I'm not sure what you mean... I never install VIPM via NIPM, it only offers an out of date version. But being stuck now, I've completely un-installed VIPM and VIPM runtime, and re-installed it from NIPM and I get the same error. I guess I should un-install LV2019 and re-install only up to 2019 f3... but that's going to take a long time

yes it is : https://www.ni.com/fr-fr/support/documentation/bugs/19/labview-2019-sp1-bug-fixes.html

After installing LV2019 SP1 f4 using NIPM I can't launch VIPM (20 or 21) anymore If anyone has an idea to solve this...

Zaphiro Technologies is looking for an experienced LabVIEW Software Developer (full time position) Details and application here : https://zaphiro.ch/career/

Well... It's your -or your employer's- choice really. I'm sure you know all the potential benefits of open-sourcing your code. Really, appart from improvement suggestions, what's gonna come at you? In my current activities I don't have a need for a sequencer but I'm sure many people would love to take a look and get inspiration, if not more. Edit : after posting the above I just read again ShaunR's signature : "A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort. (Herm Albright 1876-1944)." ;D

The initial question was : is there an open source alternative. You won't make a commercial product, good. Now... are you going to publish the source?

The link will work if you remove the extra period at the end https://rat.hampel-soft.com

What is driving you away from TestStand, just the cost or some technical reasons? I mean, you're saying you want to migrate from it, if it's just to cut costs, finding an alternative.. well even if you find cheap/free one, the cost for doing your migration will be proportinal to the size of your existing projects, so think carefully.

I've had some difficult clients in the past but it never got to that point 🤣

I've fixed quite a few bugs and changed the way timestamps are handled, now using JDP Science Common VIs for RFC-3339 You can follow on GitHub

I haven't checked how he handled comments. I started thinking about variant attributes to handle them (text and position) but it quickly gets tricky so for now I've accepted to either only read or lose comments.

Oh, and by the way, the VIP is now available on vipm.io : https://www.vipm.io/package/lv_toml/

Let me make sure I understand what you mean by this : You mean, they are ignored and don't mess up with extracting the data, right? (appart from the case in issue #1) Because for me one thing that is a bit annoying is if you load data from a TOML file that has some comments, as soon as you write using this lib, you lose all the comments, or am I missing something?

Just released v2.0.0 There's not a lot in it really, I'm hopping that the effort in improving the error reporting will help future developments like adding support for new data types and comments.

I've been thinking about this but as I said above, this a not a short term need for me. I do hope I'll find some me-time to play with comments during the summer. Interestingly, there is a reported issue on the original repo that is linked to comments : https://github.com/erdosmiller/lv-toml/issues/1

Ah.. I knew I'd screw-up the license handling... I have to say I didn't even look up how to handle open source license when forking. My bad, will fix that soon.

Timestamp support is not on my roadmap (yet) but I'll keep that in mind, thanks!

Thanks a lot for the clarification. I'll fix this in my fork.

@bjusticeI've seen issue #2 that you created on the original repo, I have to say I don't understand the problem nor the suggested solution. Could you post more info about this please?

I'm going to fork the repo on GitHub and work on it for my needs, What I'm planning to do is : short term : - move to LV2017 (just because it's the oldest I have already available on a VM) - add support for path - improve error reporting hopefully one day : - add support for comments At this point, I'm not planning to do any major refactoring. If anyone wants to participate... feel free : https://github.com/AntoineChalons/lv-toml

Well that's my case as well, and it worked with my (what we use to call) DSRL license number. As for uploading files, I created a srq last week and could upload files. Maybe things have changed since. If I go to my existing SRQs I can still upload files, I just tried, it worked. What I'm suspecting is that based on your account (partner / not partner / company, etc..) NI filters and gives you a different feature set for creating your SRQ, that wouldn't shock me.

I can confirm, it expects you LabVIEW License number. I've recently created a few SRQ via ni.com/ask The interface and the process have changed a bit, but I could describe my issue and attach files (max report amd a zip containing code).

This is great! Just in case we are thousands of LV users silently wishing for native TOML support : https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-native-support-for-TOML-file-format/idi-p/4136157

I see. Well it's great that you created it and shared it on GitHub. The tree display is also a nice feature. Now.. If jsontext gets support for comments and LabVIEW objects, it will be a no brainner.

Sounds great. I've seen you're also working issue 56, which would be another big advantage of jsontext over the TOML library.