Phar Lap and FTDI

[JimPanse]

Hello experts,

I would like to communicate via Phar Lab with a USB device that uses an FTDI chip. Is this easily possible?

Is there a RS232 to USB converter that can be used under Pharlab? A converter for a converter

I would be very grateful for any suggestions.

Greetings, Jim

[hooovahh]

What is the controller you are using that is running Phar Lap?  I've never tried any of the RS-232 USB devices with it but the cDAQ running RT Linux works great.  There is a limit to I think 12 serial devices that is a bios limitation.  I've also used some controllers that have a RJ-45 connector that has serial pinned out in it.  Also I did find this thread that might be useful.

[JimPanse]

It is a desktop PC running Phar Lab on it.

 

I assume that there is no driver for USB FTDI converter under Phar Lab. Maybe I am wrong about this.

So I thought I could use a RS232-USB converter (if there is such a converter) which then communicates with the USB-RS232 (FTDI) converter. RS232 communication works under Phar Lab.  

 

Edited June 30, 2021 by JimPanse

[hooovahh]

Oh I understand now, that is a pain for sure.  I'd try just by plugging in the device and restarting the controller first, and see if any new device is seen in MAX.  If not I don't think you'll be able to get away with a RS-232 to USB, and USB to RS-232.  I'm guessing you are going this route because there isn't any other communication methods for your device?  Obviously LXI or ethernet would be easier, and even RS-232 instead of the USB which will act like a RS-232 device, would be better.  But if you really are stuck with USB out of the device, and it isn't recognized by Phar Lap, then I don't have any other suggestions.

[ShaunR]

7 hours ago, JimPanse said:

So I thought I could use a RS232-USB converter (if there is such a converter) which then communicates with the USB-RS232 (FTDI) converter. RS232 communication works under Phar Lab.  

 

Why not just bypass the the USB-RS232 and talk directly with RS232? Wasn't the USB-RS232 used because there was no serial port, which you seem to have now?

[JimPanse]

Quote

 

This device (purchased part) has only one USB connection which was realised with FTDI. There is no other interface on it. I don't think there is a Pharm Lab FTDI driver. Therefore, the question is, is there an RS232 to USB (FTDI) adapter with which the communication could work?  Phar Lab can use RS232. Or is the approach just wrong?

Edited July 1, 2021 by JimPanse

[Rolf Kalbermatter]

44 minutes ago, JimPanse said:

This device (purchased part) has only one USB connection which was realised with FTDI. There is no other interface on it. I don't think there is a Pharm Lab FTDI driver. Therefore, the question is, is there an RS232 to USB (FTDI) adapter with which the communication could work?  Phar Lab can use RS232. Or is the approach just wrong?

No there isn't such a driver (that I would know off and is openly available). There might be in some closed source environment for a particular project (not LabVIEW related, Pharlap ETS was used in various embedded devices such as robot controllers, etc) that used Pharlap ETS in the past but nothing that is official.

There are several problems with supporting this:

1) FTDI uses a proprietary protocol and not the official USB-CDC class profile for their devices and they have not documented it publically. You only can get it under NDA.

2) Pharlap ETS is a special system and requires special drivers written in C and you need the Pharlap ETS SDK in order for this. This was a very expensive software development suite. WAS, because Interval Zero discontinued Pharlap ETS ~2012 and since then only sells licenses to existing customers with an active support contract but doesn't accept new customers for it.

Now there is an unofficial (from the point of view from FTDI) Linux Open Source driver for the FTDI standard devices (not every chip provides exactly the same FT232 protocol interface but almost all of the chips that support predominantly the RS-232, 422, or 485 modes do have the same interface) and I have in the past spend some time researching that and trying to implement it on top of VISA-USBRAW. But with the advent of Windows 7 and its requirements to use signed drivers even for a pure INF style driver like the VISA-USBRAW driver, this got pretty much useless. This signing problem doesn't exist on the Pharlap ETS system, but development and debugging there is very impractical so when Interval Zero announced the demise of Pharlap ETS, I considered this project dead too. There was both no easy platform to develop the code on as well as no useful target where this still could be helpful.

All major OSes support both the USB-CDC as well as USB-FTDI devices pretty much out of the box nowadays. This includes the NI-cRIO that are based on NI Linux RT. The only two beasts that won't are the Pharlap ETS and VxWorks based NI realtime targets, both of them are in legacy state for years and getting sacked this or next year for good.

So while it would be theoretically possible to write such a driver on top of NI-VISA, the effort for that is quite considerable and it's low level tinkering for sure. The cost would be enormous for just the few last Mohicans that still want to use it on an old and obsolete Pharlap ETS or VxWorks cRIO controller.

As to if there is a device that can convert your USB-FTDI device back into a real RS-232 device, devices based on the FTDI chip VNC1L-1A can implement this, here is an example as a daughter board. You would have to create a carrier with an additional TTL to RS-232 converter and the according DB-9 connector for this or if you are already busy building a PCB anyhow, just integrate the VNC1L-1A chip directly on it.

The most "easy" and cheap solution would be to use something like a Raspberry Pi. That can definitely talk to your FTDI device with minor tinkering of some Linux boot script in the worst case. Then you need an application on the Raspi that connects to that virtual COMM port and acts as proxy between this and an RS-232 port (or a TCP/IP socket) on the Raspi that you then can connect to from your LabVIEW Pharlap ETS program.

Edited July 1, 2021 by Rolf Kalbermatter

[JimPanse]

It's almost easier to say goodbye to Phar Lab and Labview Realtime and go for Linux RT (preempt_rt). The current RT Vision project will now run under Linux RT (preempt_rt).  Does anyone have any idea what the roadmap of Labview for Linux is? 1-2 years ago an NI employee told me that an Imaq driver for Linux should be released in the near future. Nothing has happened yet either. Therefore, I have now switched from the expensive NI PCIe 1433 cards to EURESYS GRABLINK.

Edited July 2, 2021 by JimPanse

[Rolf Kalbermatter]

As far as Phar Lap ETS goes you are definitely right. Phar Lap is a dead end and has been in fact since almost 10 years. I'm sure it was one of the driving decisions for NI to push for the NI Linux RT. It's not a coincidence that that got released about one year after Interval Zero declared Phar Lap ETS as EOL.

If you want to abandon LabVIEW RT altogether is of course a different question. You can certainly build your own Linux RT kernel, and implement your own automation software platform. I would expect such a project to take only a few man years, not being integrated as much as LabVIEW and being a continuous catch up race with adapting to new hardware since what was the hottest craze last year has already been declared obsolete today. It's a business model you could probably earn some money with, IF you intend to concentrate on doing just that. If it is to support your own automation projects, it will be a continuous struggle to keep it up and running and you will likely always be scratching the corner of barely get it up and running every time, with the plan in the back of your head to make it finally a real released product that you can rely on, but which will never quite happen.

IMAQdx for standard Linux is not likely going to happen ever. NI is not really selling image acquisition hardware anymore. They have IMAQdx and IMAQ Vision for their Linux RT targets so that's pretty much all you likely will ever get. There seems to have been a plan for standard Linux hardware drivers both for DAQmx and IMAQdx but with the current situation I'm definitely not holding my breath for it. Also hardware drivers for Linux is a very tricky business, you either open source them completely and get them in the mainstream kernel or you are constantly fighting the Linux Gods and the Distribution Maintainers to keep your drivers running with the latest software and will never be able to make it work even on 50% of the installed Linux distributions out there. Add to that the fact that outside of servers (where automation software with DAQ and IMAQ are extremely seldom of any interests) the Linux market share is pretty small. And the majority of those who do use Linux outside of server environments are more likely to tinker for months with YouTube videos that explain often more than questionable hacks to achieve something, than pay some money for hardware and software other than their PC rig with RGB LEDs and watercooling. For a company like NI that makes this market simply VERY uninteresting as there is simply not much money to be earned but the costs are enormous.

Edited July 2, 2021 by Rolf Kalbermatter

[JimPanse]

I haven't yet found the "egg-cellent" in the area of real-time, vision and automation. A few years ago, I thought Labview RT based on Phar Lab was it. There is no RT Linux Labview for Desktop PCs. From my current point of view, a modified RT Linux is a possibility to realise these requirements. And I need the variety of hardware solutions that a desktop PC offers. The NI hardware is too limited and does not offer many possibilities. And with the NI software solutions, you don't know how long they will be supported. In your opinion, which development environment is best suited for such applications?

 

 

[Rolf Kalbermatter]

50 minutes ago, JimPanse said:

I haven't yet found the "egg-cellent" in the area of real-time, vision and automation. A few years ago, I thought Labview RT based on Phar Lab was it. There is no RT Linux Labview for Desktop PCs. From my current point of view, a modified RT Linux is a possibility to realise these requirements. And I need the variety of hardware solutions that a desktop PC offers. The NI hardware is too limited and does not offer many possibilities. And with the NI software solutions, you don't know how long they will be supported. In your opinion, which development environment is best suited for such applications?

If performance is of no concern for you AND you don't care about licked GUIs for your apps, Python is a good option nowadays. How long that will be before there is a new kid on the block to whom everybody is catering to and declaring everything else as from yesterday, is of course always the big question.

Python with it's automatic data type system is both easy to program and easy to botch a program with. And such flexibility has of course a performance cost too 😀, as every variable access needs to be verified and classified before the interpreter can perform the correct operand on it. And while you can pack large datasets in special containers to be performant, the default Python array object (list) is anything but ideal for big data crunching.

Other than that I think I would stick to C/C++ for most of the things if I would abandon LabVIEW.

[hooovahh]

On 7/5/2021 at 2:44 AM, JimPanse said:

There is no RT Linux Labview for Desktop PCs. 

I searched and couldn't believe I couldn't find an idea on the idea exchange for this so I made one here.  There is a related idea of having a VM of the Linux RT environment, and some comments in the post outline how to do this.  Using the method described you can have Linux RT on a desktop, but there is no support from NI, and in my experience network driver support is limited.  It is also a licensing issue as others have pointed out, since NI's drivers aren't licensed for this unofficial hardware even if the kernel and Linux core is less restrictive.

[Neil Pate]

20 hours ago, hooovahh said:

I searched and couldn't believe I couldn't find an idea on the idea exchange for this so I made one here.  There is a related idea of having a VM of the Linux RT environment, and some comments in the post outline how to do this.  Using the method described you can have Linux RT on a desktop, but there is no support from NI, and in my experience network driver support is limited.  It is also a licensing issue as others have pointed out, since NI's drivers aren't licensed for this unofficial hardware even if the kernel and Linux core is less restrictive.

Excellent idea, I have added my kudo! I don't think this will get much traction from NI but it would be really nice to see this as something semi-official.

Once you know what you are doing it is not super complicated to get RT linux running on a desktop.

[Rolf Kalbermatter]

4 hours ago, Neil Pate said:

Once you know what you are doing it is not super complicated to get RT linux running on a desktop.

No, but without a legal license for NI-LabVIEW Realtime Runtime and all the various NI-other software, it's a complete nogo for anything else than your home automation project.

[Neil Pate]

6 minutes ago, Rolf Kalbermatter said:

No, but without a legal license for NI-LabVIEW Realtime Runtime and all the various NI-other software, it's a complete nogo for anything else than your home automation project.

Exactly why we need NI to buy in to the idea, otherwise it will never get off the ground.

[dadreamer]

Another option would be to get NI's hands on IntervalZero RTX64 product, which is able to turn any Windows-driven computer into a real-time target. That would definitely require writing kernel drivers for NI hardware and some utilities/wrappers for LabVIEW to interact with the drivers through user-space libraries. Of course, the latter is possible now with CLFN's but it's not that user-friendly, because focuses mainly on C/C++ programing. Not to mention, that a limited subset of hardware is supported.

[Rolf Kalbermatter]

17 hours ago, dadreamer said:

Another option would be to get NI's hands on IntervalZero RTX64 product, which is able to turn any Windows-driven computer into a real-time target. That would definitely require writing kernel drivers for NI hardware and some utilities/wrappers for LabVIEW to interact with the drivers through user-space libraries. Of course, the latter is possible now with CLFN's but it's not that user-friendly, because focuses mainly on C/C++ programing. Not to mention, that a limited subset of hardware is supported.

Now that's not just dreaming but fantasizing. 😀

Developing a new LabVIEW target, even if it could reuse most of the code for Windows, which I'm not sure would be the case here, is a major investment. Why would they want to do that if they already have LabVIEW NI Linux RT?

And the main reason that there is no LabVIEW NI Linux RT for Desktop solution is that NI hasn't figured out (or possibly bothered to figure out) how to handle proper licensing. They do not want to enable some Chinese copycat shop to develop their own RIO hardware and sell it with the message "Just go and buy this NI software license and you are all legal". That such hardware can be developed has been proven in the past, it basically died (at least around here, maybe they sell it in tenthousends per month inside China) because such a solution did not exist and anyone using that hardware was not just operating in grey area but fully forbidden territory, with lots of legal mines in the ground.

Edited July 8, 2021 by Rolf Kalbermatter