read excel file in RT

[brimcd]

I usually define my data systems in Excel, then read that definition to set up the hardware configuration. Works great in windows, but obviously I can't use windows functions (ActiveX) in RT . My current solution is to configure in Excel, export to CSV or XML, and read that for the RT system setup.  Are there any Labview-RT (Phar Lap) solutions to reading Excel files directly?

Thanks.

[GreyGrey]

Hi brimcd,

Using LabVIEW Real-time, there is not a way to read Excel files.  Alternatively,  you could read the excel file on another desktop machine and transfer the information from the Excel file over to the RT controller. 

[metux]

http://search.cpan.org/~ken/xls2csv-1.07/script/xls2csv

[GreyGrey]

Hi metux,

You may be able to get that to work on LinuxRT but it wouldn't be supported by NI.

[metux]

---

@GreyGrey wrote:

Hi metux,

You may be able to get that to work on LinuxRT but it wouldn't be supported by NI.

---

I know, NI doesn't support Linux applications on cRIOs at all - they just use it as loader for the LV runtime ...

That's why my clients won't even consider buying them.

[dklipec]

---

@metux wrote:

---

---

I know, NI doesn't support Linux applications on cRIOs at all - they just use it as loader for the LV runtime ...

---

False.

Getting Started with C/C++ Development Tools for NI Linux Real-Time, Eclipse Edition
http://www.ni.com/tutorial/14625/en/

Further, the original poster asked about Phar Lap, not LinuxRT.

[metux]

---

@dklipec wrote:

---

---

False.

Getting Started with C/C++ Development Tools for NI Linux Real-Time, Eclipse Edition
http://www.ni.com/tutorial/14625/en/

But w/o any access to the cards (official statement from NI) - which makes it pretty useless.

[dklipec]

Again false.  This compilation flow is supported for RIO based targets with a public driver.

We all understand that the manner in which some devices are supported is not acceptable to you.  You've used more than 90% of your approximately 100 posts to say that, across dozens of threads, in ways that are not constructive, often misleading, and generally distracting from the topic under discussion.  There are more effective ways to communicate your desires than the way you have used thus far.  You would be more effective at accomplishing your goals if you stuck to them.

[metux]

@dklipec wrote:

Again false.  This compilation flow is supported for RIO based targets with a public driver. 

Where is the driver source code ?!

I'm speaking of drivers for cRIO backplane and cards.

In last call NI officially told there are no Linux drivers at all - everything's tied into LV (and the code it generates). And that's also tied w/ LV-generated bitfile for the fpga (IOW: there's even no defined cpu<->backplane interface).

Maybe it's nice, if you're doing everything in LV. But we don't use LV at all - we have no use for it (far out of scope for us). We just need Linux-supported industrial computers w/ some ADCs and DIOs.

Perhaps NI only wants to sell cRIOs for LV-users exclusively. Fine. But then stop claiming Linux support. The problem here, which is really annoying me is: these devices are offered for Linux applications (instead some LV-programmed controller that just happens to run a Linux kernel), so people buy these boxes under wrong assumptions (in Germany could be considered unfair business - maybe I should trigger an legal dissuasion ?). My clients went into that trap - bought an expensive devices which is completely useless to us. (their plan was to buy several hundreds, but that's now completely off the table, thanks to my intervention) 

We all understand that the manner in which some devices are supported is not acceptable to you. 

Fine, but it is there anything done about that ? Doesn't seem so.

Just understanding, w/o any actual actions doesn't solve any problem.

You've used more than 90% of your approximately 100 posts to say that, across dozens of threads, in ways that are not constructive, often misleading, and generally distracting from the topic under discussion.

This approach at least led to some NI folks at least speaking to me. Official contact attempts had no effect.
Lesson learned: you'll have to make noise and put a lot salt into the wound, to get things moving.

Lesson #2 learned: you'll have to repeat it if things fall back asleep.

There are more effective ways to communicate your desires than the way you have used thus far. 

See above: this already failed. 

The only thing at at least triggered an action was exactly this kind of noise.

And: the problems of lots of other people here (not just cRIO, but also the other devices) are also caused by this ridiculous Linux driver situation. Begins with the technically absurd idea of kernel blobs (leading to ridiculous situations like breaking w/ too much RAM, no support for not-ancient kernels, etc, etc). As a Linux expert and consultant, I have an moral obligation to warn people who don't have my knowledge.

I'd estimate the damage done by that (including costs for maintenance, workarounds, support, lost customers, etc) are magnitudes higher than the costs of clean IIO drivers (which could have been mainlined years ago). The loss of my clients as customers is already factors higher.  

From an SW architect's PoV the whole idea of trying some "cross-platform" HW drivers, is silly to begin with. Drivers is one of the core areas of operating systems - they vary heavily (even within the *nix world). They all have their different native infrastructures / APIs - trying to work around them just causes *huge* pain (and finally much more expensive than clean drivers for specific OSes). 
If you wanna have some crossplatform API for applications (eg. LV), just let that API call the OS'es native drivers APIs (whichever it might be on a particular OS).
For Linux, the native API for those kind of devices is IIO. 

[dklipec]

---

We all understand that statement.  You've made it literally a hundred times.  Bugging NI and NI's customers on the forums by interfering in genuine support is unprofessional.  Please restrict your replies to being helpful and use the sales and marketing channels as a way to escalate your needs from our products.