Labview RT and Pharlaps ETS

[jF-Solutions]

Hello,

I have to look into a system that does not perform ideally (seems limited in execution time, ...) 

The system is using Labview RT 2017 (some machines are running 2015), running on an industrial PC running Phar Lap 13.1 .

I am surprised of this as I thought that Labview RT 2017 would require mandatory NI-ETS 2017. But it seems to run ...

What kind of difficulties is to be expected when the version of Labview RT and ETS (phar lap) do not match ?

Is there a paper from NI discussing the potential issues in detail, more than the already found http://www.ni.com/product-documentation/53636/en/  ?

Any help, ideas, suggestion would be appreciated.

Thanks in advance.

J.F.

[Bob_Schor]

In my limited (about a decade) experience (only PXI boxes), the version of LabVIEW and the PharLap OS on the Target must be the same.  In particular, whenever I upgraded (or downgraded) the version of LabVIEW that talked to the Target, I also reconfigured the Target, replacing the OS and the supporting DAQ routines.  When I did this, the code seemed to work (unless I "programmed in" a bug, of course ...).

Bob Schor

P.S. -- this is what worked for me.  That doesn't mean to say that there might be a way to "mix and match" OS and DAQ versions between Host and Target, but when I forgot to update, things didn't work, and when I did, they worked a whole lot better ...

[jF-Solutions]

Thank you Bob, for this quick reply.

I'm interested in knowing the kind of problems we should expect, when versions are not matching, in order to verify if this could be a root cause for poor performance of the application I need to investigate.

Any example of effects when mixing versions of Labview-RT and ETS-Pharlap ?

I'd like to have a good confidence that I need absolutely to update the ETS-Pharlap before proceeding.

Thanks in advance.

J.F. 

[Bob_Schor]

I'm assuming that the Host PC and the PXI Target are "connected" via TCP/IP.  If so, open MAX and have it look for Remote Systems.  With luck, it will find your PXI.  If so, expand the Remote System, paying attention to the installed Hardware and Software.  Does everything look OK?  Can you run Test Panels on the installed modules?  Do you see Software conflicts?

Sadly, I'm busy (once again) doing a "Remove/Reinstall All NI Software)" (MAX suddenly stopped working, could not be "repaired") or I'd fire up my PXI (which probably is not software-compatible with my new system) and show you how this might appear ...  But feel free to attach screen shots of your Remote Software settings in MAX.

Bob Schor

[jF-Solutions]

Hello Bob,

they are using an industrial PC (with a Xeon 8 core processor), running Pharlap ETS, not a PXI.

MAX finds the system OK. See the attached screen shot.

The boards are OK and I do not see any conflicts.

What I'm concerned with is the version of the OS, Pharlap ETS 13.1, with Labview RT 15.0 .
I have read that we should have, with Labview RT 15.0, NI ETS 15 as the OS for correct compatibility.

It seems it is not the case on this set-up. Before upgrading the RTOS, I would like to have a good understanding of the kind of issues such configuration can generate ... and have a good level of confidence that upgrading the OS will improve performance. 

Thanks for your help and advices.

Regards.

J.F.

[Bob_Schor]

Thanks for the clarification -- I've heard about using a PC as an RT processor by installing an RTOS, but as I recall, there are things that an RTOS doesn't do well (like displays, keyboard interaction, file I/O), or at least things that when running with a PXI-box I handled in the Host, not the PXI.  Still, with LabVIEW being the stickler for "version compatibility" that it is, it seems reasonable/possible that having all of the components be at least version-compatibile is a Good Thing.

Bob Schor