Mads

I meant that the VIM is member of a class yes. I've been informed now that this can be achieved as long as the VIM uses an accessor when operating on private data...Now at first that did not seem like a solution as I then expected the accessor to have to be public, and I do not want that particular private data available at all, but the accessor *can* be private, so that makes it a solution. Not a very intuitive one - but at least it is doable. (It seems a bit strange that the VIM is not allowed direct access to private data, but it can still call a private method to effectively do the same thing (so why not allow it to access the private data without the accessor in the first place...)).

Just ran into an issue with malleable VIs I had not thought about before, and now that I have I cannot find any mentioning of it anywhere (?): Because mallable VIs have to be marked as inlined, you cannot use them in classes if the VI is to be public.... It then breaks because inlining it means accessing private data in the calling function. In my case I wanted to use it instead of a polymorphic approach to supporting read/write operations with different data types on a file class. Or am I missing something? It all reminded me a bit about this old thread about the lack of support for polymorphic VIs in classes -

The platform bundle web downloader looks more like the right one (http://www.ni.com/download/labview-development-system-2018/7406/en/). It does not state the name "Platform Bundle" until you have drilled down a bit. I see now that that one does not include NXG, nor the OPC toolkit either (unless the latter has been renamed and is part of the communications package?). Have they chosen to separate NXG completely, contrary to what was done in 2017?

Should not NXG and the OPC toolkit be available in the Developer Suite download? Or is there an even bigger package? A bit confused by all the variants, went for the Developer Suite as that is what our set used to be called...But NXG was at least included in the set we got on USB-sticks in 2017 (changed now?), and we also have OPC licenses... The latter might always have been a separate download (not sure why it still is though...)?

Donated. Cool initiative. I wonder how much faster you will be able to run the 10K (or Half/Full Marathon) after the year is finished.

VIPM disappeared on my machine as well. Perhaps NI should make an SP1f2...

Ah, yes. I actually downloaded the full SP1 from a different web page, but found the f1 link when I was about to post it here. The SP1 package is here: http://www.ni.com/download/labview-development-system-2017-sp1/7099/en/ Once SP1 is installed there is also an SP1 f1...Which my NI Update Service notified me about as soon as I had installed SP1. The SP1 package is much larger than f1, so I guess you have to install that prior to SP1f1.

Perhaps old news for many, but my NI Update Service does not tell me these things for some reason (yet to figure out why, it does bring other less needed updates to my attention...) and I have not seen anything about it elsewhere either, so perhaps it is news for others as well: I accidentally noticed that 2017 SP1 has been released . It was posted one week ago, on the 23rd of January...

That was kind of implied. Instead of going that probabilistic route though, we just get the masters to pause enough in front of the messages to our slaves to avoid the issue. It's never been a problem to get the control system operators to accept that (they are normally quite strict on things, but not that particular configuration).

We do both. As I mentioned 3.5 byte times is extremely short for a Windows-machine, at least at higher baud rates but most control systems for example make this time configurable anyway. That's the main point - the master should not issue commands too quickly in a row. It's not really a problem if there are slaves that will reply faster, because getting non-relevant messages garbled by having both the poll and reply together in the same serial buffer is no problem (it should just be discarded anyway). The problem is if the master shoots another message addressed to your slave too quickly after getting the previous reply. Then you are not able to separate that relevant data from the previous irrelevant messages.

Oh non-broadcast messages can pose a challenge too, if you have multiple other slaves on the same line replying instantly after 3.5 byte times... Broadcasts on the other hand are seldom used in the systems we deal with, and when they are, its mostly directed towards our non-Windows targets (which in our case means sensors running assembly or Visual-DSP based code instead, with no problem handling such short silence times).

Personally I prefer the modbus way here; using silence time as markers for the end of messages. And I really do not want to chew on that data in a hunt for an ID with a CRC that just probably indicates a valid message (although the chance of a false positive is low, we are dealing with a *lot* of messages here...). Calculating lengths is also messy with modbus, as many messages have unpredictable lengths (Modbus should have had a header with the length in a fixed position...Instead each function code is different, not to mention user defined ones). As for not using any of the libraries already out there I share many of your sentiments James. Linking the modbus handling tightly with the rest of the application though is something we have mostly avoided. We use an in-house library that deals with the fundamentals of generic modbus only, and have other code add layers on top of that instead just using the registers. I did have to insert some user defined function code forwarding into the library once to make a generic robust file transfer (ZMODEM inspired) and command protocol on top of modbus though...That solution allows us to upgrade the software on our subsea embedded PACs, and use various TCP/IP based protocols transparently over a serial Modbus RTU link when no Ethernet is available :-) It would have been nice to have something like that be part of the Modbus standard instead though.

Basically the RTU slave should continuously check its serial port, and if there is any data there it should recheck the port until no new data has been received for those n milliseconds. Then it should process the received message. If the message is intended for a different ID it should just discard the data (clearing its serial buffer for another message). Using 3.5 character silence time can be a bit challenging yes. Windows at least seems to add delays every now and then (it's not deterministic...), so even in a tight loop you can get into that kind of territory (typically you will see this as a problem that increases the longer the Modbus messages are, as the probability of an incorrectly detected halt will then increase...). Luckily most of the time the Modbus Master can be configured to put more silence between polls (interframe delay or similar configuration), making it easier for slaves to clear their input buffer between polls to receive separate messages. We have dealt with most of the control systems used in the oil and gas industry over the years, and have never had an issue after the initial setup (All of them can extend the silence time if needed, and/or chop the messages into shorter ones). Instead of 3.5 byte times at a baud rate of 19200 for example, we might end up using 10-30 ms.

We found the solution now - and it was not the firewall. Two cookies had to be deleted, but only those two (so deleting all cookies did not solve anything). The two cookies were an_ca and an_cci. Perhaps the reason was that the two contained street addresses with Norwegian characters...I do not know that yet. I've sent the info to NI.

Seems to have been triggered by an automatic update on a Palo Alto firewall yes... It does not block anything when I'm not logged in, and the URL does not change when you are logged in so I have not pin-pointed what the issue is yet, but anyway. (Created a Virtual Machine on Google Cloud just to prove the issue to the firewall admin. Quick and easy solution if you need access to a clean test PC on the outside of the firewall by the way...).

Yes, I do not think it is a global phenomenon...I'm one of the few lucky ones

Not related to lavag.org, but forums.ni.com...and the problem prevents me from posting anything there, so I'll try here: As soon as I log in on forums.ni.com, regardless of which machine or browser I use, I get server error 500 on all pages on forums.ni.com. So I'm effectively locked out of ni's discussion forums. I've tried requesting help on this by creating a service request at ni.com, but the only reply I got back was that they did not handle web site trouble so please post it here *** instead...Which I did, with no reply at all. Has anyone else experience this? Error 500 is server side as far as I know, and as I mentioned it does not really matter what I use to browse the page...so my guess is that there is something wrong with my account that NI has to fix.

Rigid VI Implastic VI In-elastic VI Change-resistant VI Less adaptable / Low-adaptable VI High-friction VI Dodo-VI High-maintenance VI Costly VI Slow-moving VI Detour-VI Roundabout VI Brick of a VI .... 204. Unpliable VI...

The problem does not seem to be Linux RT as such, but the cRIO-9030 - so probably the fact that it is x64. I took the same code and ran it on a cRIO-9063 (ARM) which also runs Linux RT, and it works as it should.

Any news on this Rolf?

I copy them to a Windows computer and open them there with Explorer. I just reduced this down now to compression of a single file on a cRIO-9030 with LabVIEW 2015. The input and output files, plus the source (just the top level) is included in the attached file. Zip test.zip I've also attached a capture of the subVI front panels in the call chain, if that might offer any clues.

It seems as far as I've established so far that everything that gets passed on to the linked library calls are the same on the Linux target as on Windows, (the file attributes e.g. are calculated to be 0) but the resulting file has minor changes (attribute flags I presume; I have not gotten into the details of the format yet) in the first and last lines of the archive. Otherwise the content is identical (in other words the files are there, but incorrectly identified as directories so I do not get to their content). Perhaps it has never worked on these Linux RT targets :-O I hope I'm wrong. I know the deflate/inflate works on Linux RT targets, but discovered now that for the directory compression a different method had been put in place at some point in time for the cRIO-9030, so I was wrong when I said it had worked before...It was, it seems, just due to an override on those targets.

LabVIEW 2017 with OpenG Zip Tools 4.1.02 on cRIO-9030 (Linux RT target). I had a piece of code developed in LabVIEW 2015 for a cRIO-9030 where a folder is compressed with the Zlib Compress Directory function, and it has worked for years...Now I converted it to LabVIEW 2017, and for some reason any files (lots of .ini files) in the directory will now end up as folders. What is even stranger is that if I debug I can see that the files are detected as files as they should by the zlib file information VI. I seem to remember having run into a similar issue a long time ago, but I cannot remember what the solution was.. Or perhaps it is a new issue on 2017? I'm in a bit of a hurry so I'm throwing out a question here just in case I get a response before I've spent more time on it...Any ideas?

The biggest headache with USB is BadUSB. I trust NI will make sure their USBs are OK though, I do not miss the DVDs (CD-ROMs? That must have been back in the LabVIEW 7/8 days ;-)).

I tested 2017 vs 2015 now, and the behavior does seem to have changed (have not checked the behaviour in 2016 though, skipped that version): In 2015, double-clicking a preallocated reentrant sub-VI in both edit or run-mode (not actually executing it, just double-clicking on the VI while the code is running) will open the front panel of a clone (noted in the window name). In 2017, it opens the master VI (the cloned window is not available until the subVI is executed).