All Activity

VxWorks is quite special. It looks on many fronts like a Posix platform, but that is only a thin and not complete layer above the lower level and very specialized APIs. Programming to that lower level interface is sometimes required for specific operations but documentation was only available as part of the very expensive developer platform with according compiler. It's of academic interest now since VxWorks has been deprioritized by WindRiver in favor of their own Linux based RT platform. And NI has long ago stopped using it and never made the move to anything beyond 6.3 of the OS. It was anyhow only intended for the PowerPC hardware since they moved to that platform as power efficient embedded targets were not really an option on x86 based hardware at that time. But with the PowerPC loosing pretty much all markets, it was a dead end (at some point in time it was the most used embedded CPU solution, many printers and other devices, where users never ever saw anything of the internal hardware, were running on PowerPC). It was hard to port any reasonably sized code to VxWorks because of the higher level APIs often being very similar to other Posix platforms like Linux, but not always working exactly that way or not providing certain functionality on that level. Accessing the lower level API was very difficult because of the very limited documentation about it that could be found without investing an arm and a leg into the developer platform from WindRiver. But once that porting was done there was fairly little maintenance required both because the API stayed fairly consistent and NI didn't move to a different version (except VxWorks 6.1 to 6.3 between LabVIEW 8.2 and 8.5).

Not so much mind boggling - I used to support VxWorks . It's not just Apple OS's though. Linux is similar. The same mind-set pervades both ecosystems. I used to support Mac, Linux and Windows for my binary based products because LabVIEW made it look easy. Mac was the first to go (nobody used it anyway) then Linux went (they are still in denial about distribution).

Unfortunately, Apple manages to almost consistently break backwards compatibility with earlier versions for anything but the most basic "Hello World" application. And yes that is only a mild exaggeration of the current state of affairs. For an application like LabVIEW there is almost no hope to be compatible over multiple OS versions without some tweaks. Partly this is caused by legacy code in LabVIEW that uses OS functions in a way that Apple has declared depreciated versions ago, partly it is simply because that is considered quite normal among Apple application developers. For someone used to program to the Windows API, this situation is nothing short of mind boggling.

It doesn't have to. Just back-save () to a version that supports the OS then compile under that version. If you are thinking about forward compatibility then all languages gave up looking for that unicorn many years ago. That is excellent news.

It seems they are going to make normal ordering of perpetual licenses possible again. While the official stance was that the perpetual licenses were gone, the reality was that you could still order them but you had to be VERY insisting, and have some luck to know the right local NI sales person, to be able to order them. That will of course not help with a current Macintosh version of LabVIEW. Still, maybe some powers to be might decide that reviving that is also an option. Kind of doubt it as I have experience with trying to support Mac versions of LabVIEW toolkits that contain external compiled components and the experience is nothing short of "dramatic". But if there would be a client teasing NI convincingly about ordering a few thousand seats of LabVIEW if there was a Mac version available, I'm sure they would think very hard about that. 😁

Judging only by your attached image. The Array that is being chained through your DLL calls has conversation dot (red dot) that shows you are auto typecasting. Make sure all inputs to DLLs have exact data type and length. If passed by reference or by value etc.

It works... Thank you so much, I didn't understand this table contains all the info I wanted Thank you again ! KR, Bilsix

Why don't you just try it? Open your SQLite viewer app if choice and execute "SELECT * FROM sqlite_schema"

Thanks for your answer Dr. James ! In fact, the database is already created, I only would like to read the tables already created in the database, I don't need to create a new table. Do you confirm sqlite_schema is the request I need to do so ? Thx & KR ! Bilsix

You're looking for the sqlite-schema table: https://www.sqlite.org/schematab.html

Hello world, Thank you so much for the great work drjdpowell !! Wonderful library ! I have a question concerning the possibility to get all the tables of a database : is it possible to list all the tables of a database (here an array containing [table_1, table_80, Table_9012]) with the library ? It seems the ".tables" request in SQLite is not understood: I tried a lot of other request, ("show tables", "SELECT * FROM information_schema.tables;", etc), same result. I'm working with LabVIEW 23 Q3. Does somebody know if there's a solution for my problem by using this library ? BR ! Bilsix

Looking for a Freelance Labview Programmer in the Phoenix ,AZ area.

Hello. I found my program lists (to a text file) a similar info that is shown by "All Methods and Properties.vi" - likely something was added since creating the VI - an excerpt from XNode property list: p: 632a804 Width 'Area Width' 'Bounds:Area Width' r: Width (U32) p: 632a817 DependNames 'DependNames' 'Dependencies:Found Dependency Names' r: DependNames (Array) p: 632a816 DependPaths 'DependPaths' 'Dependencies:Found Dependency Paths' r: DependPaths (Array) p: 632a815 MissingNames 'MissingNames' 'Dependencies:Missing Dependency Names' r: MissingNames (Array) p: 632a814 MissingPaths 'MissingPaths' 'Dependencies:Missing Dependency Paths' r: MissingPaths (Array) p: 632a808 GrpMbrRefs[] 'GrpMbrRefs[]' 'Group Member Refs[]' r: GrpMbrRefs[] (Array) The attached ZIP contains the the program, the entire file produced by my program for LabVIEW 2018, and more. The file lists all LabVIEW classes found (287) and is over 100 000 lines long (it can be made much shorted by omitting properties/method inherited from parent of each class, but till now I didn't manage to perform the compression). Class properties and methods information format: 😄 (class info) p: (property info) (t): (terminal info) m: (method info) (t): (terminal info) For property, the (t) may be "r", "w", "r+", "w+", specifying read or write mode, and capability to change (e.g. "r+" means read that can be changed to write, "w" means write-only). For method, the (t) is either "i" or "o", specifying input (host to method), or output (to host) terminal; note some terminals have empty names. The file from the program contains 2468 different properties (i.e. w/ different names), and 1168 different methods. Its name "lv_classes+pmt.txt" stands for "LabVIEW classes + Property and Method Terminals". lv_classes.zip

Linux has also a nice tool named "strings". Using these together: strings some.vi | grep \\.vi can produce an output like: !eio_Utilities_GetNonAliasNames.viPTH0 EIO API!eio_Utilities_GetNonAliasNames.vi EIOPlaceDownEIOPropertyNode.vi EIOPlaceDownEIOPropertyNode.vi EIOPlaceDownEIOMethodNode.vi EIOPlaceDownEIOMethodNode.vi Get Type Information.vi Get Type Information.vi Get Type Information.vi EIOPlaceDownEIOPropertyNode.vi EIOPlaceDownEIOMethodNode.vi !eio_Utilities_GetNonAliasNames.viPTH0 EIOPlaceDownEIOMethodNode.vi EIOPlaceDownEIOMethodNode.vi Get Type Information.vi Get Type Information.vi EIOPlaceDownEIOPropertyNode.vi EIOPlaceDownEIOPropertyNode.vi !eio_Utilities_GetNonAliasNames.viPTH0 EIO API!eio_Utilities_GetNonAliasNames.vi some.vi The "strings" tool on Ubuntu 18.04 is in a "binutils" package.

The problem is that some day the customer will buy a new Apple laptop and that new laptop will not support LV2023. We need maintenance releases of LabVIEW RTE to keep it all working.

Hi, it may be a stupid question, but I'm not too deep into Labview yet. I want to read out values from a battery via a DS28E17 and display them. Now my question is how to do this with TMEX. My current setup is as follows. I can output the ROM number without any problems. But not the voltage from the battery or the DS28E17 does not pass on my commands to the battery.

This wouldn't be much of an issue since you could always use an older version of LabVIEW to compile for that customer. However. Now LabVIEW is subscription based so hopefully you have kept copies of your old LabVIEW installation downloads.

Most customers use Windows and that is the primary target. We want to support all our customers though.

Ok, would it take a lot of work to port it to Linux desktop or Windows?

There's a PXI based hardware system that generates TDMS data logs and the project is a viewer/analysis tool for those data logs.

Out of curiosity, can you describe a bit your customer project that runs on OS X?

I was about to build an executable for a OS X customer when I noticed that it won't be possible for much longer: https://www.ni.com/en/support/documentation/compatibility/18/labview-and-macos-compatibility.html This surprised me because I know the founders were hard core mac enthusiasts and also because usually large companies will put something like this on their road maps so that people can plan better.

Has anyone found the solution to @gyc problem? I have a similar problem. I modified the config file as follows: [1-Wire] PortType=DS9490R PortType possible values=DS9097E, DS1410E, DS9097U or DS9480, DS9490R or DS9490B PortNumber=1 EnhancedOptions=Not use EnhancedOptions possible values=Not use, SESSION_INFINITE, SESSION_RSRC_RELEASE, SESSION_NO_FORCE_REG_SPD At the end, I would like to be able to read the volts from a sample via a DS28E17. Is this even possible with this?

The structure should be as follows: - PC talks via the DS9490R or RS232 to the DS28E17 - the latter transmits the 1-wire commands to the DS28E17 - The DS28E17 converts the commands into I2C and sends them to my test object - which in turn sends back the volts to be measured - the DS28E17 stores this in its internal memory - The memory with the value is read out via PC and adapter

I have an LDO for 3v3. The setup also works so far that I can read out the ROM, with the device-specific command 33h and directly via TMAX.