02-10-2015 08:40 AM
I was unable to initialize a serial port on a cRIO-9030 using a code that works fine on VxWorks and Windows, when I tracked it down to this somewhat strange behaviour;
If you call VISA Set I/O Buffer Size on Linux RT (at least on the 9030 device) you will get error code 1073676424 for all size values other than 0.
That is a bit strange (what will the buffer size be then I might add...), but something even uglier is that if you leave the function's buffer size unwire, you will also get the error (because the function's default is 4096).
12-13-2015 02:53 AM
Hi!
I confirm the above behaviour for the cRIO-9068 too.
I developed my application using an sbRIO-9636, before buying the final platform the cRIO-9068. I need to acquire 3 RS232/485 signals (from motion sensors) at 100Hz each resulting to buffers 10kb/sec. Using the "VISA set I/O buffer" technique, I have configured the VISA buffers to hold several seconds of data, doing a sort of continuous double-buffering acquisition, concurrently with my FPGA channels.
The concept proved to work fine. A test on cRIO-9076 run ok too.
Therefore we bought the flagship cRIO-9068, as we need +4 C-modules for the final setup. And now comes the big DISAPPOINTMENT: It seems that cRIO-9068 does not support user-defined VISA buffers, which are supported in lower cost RIOs !!
Let's hope that it is just a driver bug and this can be resolved rather quickly.
But issues like that raise the subject of hardware platforms upgrades. We can never be sure...
Regards,
Dimitri
12-13-2015 11:04 AM
Do you have a small example that shows this?
I can recreate code, but I want to make sure I'm not oversimplyfing things. It sounds like you'll see this problem if your RT code contains nothing more than creating a VISA task and trying to configure the buffer. Is that right?
12-14-2015 03:23 AM
Basically this is a problem whenever the VISA buffer size is to be set on a serial port. So open a serial port with VISA and then try to set the buffer size....
(In my case I was using a code that was basically identical to the legacy Serial Port Init.vi when I first ran into this issue).
12-14-2015 03:28 AM
Hi natasftw !
Yes, as you may see in the attached picture, it's as simple as that, to reproduce this error.
Thanks for looking at it,
Dimitri
12-14-2015 03:55 AM - edited 12-14-2015 03:59 AM
If you look at the help for the Set I/O Buffer Size function - there's a note at the top which says:
Not all serial drivers support user-defined buffer sizes so some implementations of VISA might not be able to perform this operation.
It also says you need to run the Configure Serial Port VI first.
Either - the VISA serial driver on Linux RT doesn't allow user-defined buffer sizes, you haven't called Configure Serial Port first or it might be an issue with the particular version of Linux RT / VISA you have installed on your target.
The error you are getting is actually a warning - it's not an 'error' - so it's probably that changing the serial buffer size isn't supported for Linux RT. If you look up the description of the error code:
1073676424 | The specified I/O buffer is not supported. |
12-14-2015 04:32 AM
Hi Sam_Sharp!
Probably, you haven't read above, where I explained my appoach.
I am very disappointed because before buying expensive hardware, I completed successfully the test, twice, to lower-cost platforms.
When you read the definitely misleading note at the help of Set I/O Buffer Size function (Not all serial drivers support user-defined buffer sizes so some implementations of VISA might not be able to perform this operation) would anybody assume that this refers to superior or older and inferior hardware? I guessed the second.
Why am I using the term misleading? Because looking at the site, this is first reported in 2004 and has to do with a VISA limitation when using the POSIX serial API. This is valid for all Unix/Linux targets. Can you give me a reason of not saying this at the function's help?
Regards,
Dimitri
12-14-2015 04:48 AM - edited 12-14-2015 04:52 AM
Yes, I did read your post.
Whether or not the Serial driver supports user-defined serial buffer sizes has nothing to do with being older/newer inferior/superior. It's down to the serial driver and whether or not the functionality has been implemented (in hardware as well as the software driver) for changing the buffer sizes. The newer cRIOs are based on Linux, the older ones run VxWorks or Pharlap - so it might even be that it's not supported in the OS (as VISA interacts with the OS).
I don't work for NI so I couldn't say what the reason is for it - but I guess because of the huge number of serial device manufacturer's and different OSes that NI works with, it's almost impossible to test/list every one to see if that particular function is supported by the serial driver.
Usually NI Sales are pretty helpful when it comes to checking if the hardware you have will/will not support a certain function. We've sometimes been given loan hardware for testing things out.
(Of course, you can always code around the buffer sizes you have available...either reading/writing more often or using the bytes written to verify all of your data was sent)
12-14-2015 09:22 AM - edited 12-14-2015 09:36 AM
@dfousek wrote:
would anybody assume that this refers to superior or older and inferior hardware? I guessed the second.
There's the mistake there. As Sam says, it's always possible to get hardware to test on instead of blindly relying on one aspect of a particular hardware interface.
At least NI has this in their help, so it cannot be calimed that it's totally unexpected.
I agree though that the current situation is really not very helpful, it's almost impossible to know in advance if hardware will support this or not. I've also been bitten by this in the past. Code which ran for years suddenly stopped working on a new machine. Much head scratching ensued.
12-14-2015 05:43 PM
@Intaris wrote:
@dfousek wrote:would anybody assume that this refers to superior or older and inferior hardware? I guessed the second.There's the mistake there. As Sam says, it's always possible to get hardware to test on instead of blindly relying on one aspect of a particular hardware interface.
At least NI has this in their help, so it cannot be calimed that it's totally unexpected.
I agree though that the current situation is really not very helpful, it's almost impossible to know in advance if hardware will support this or not. I've also been bitten by this in the past. Code which ran for years suddenly stopped working on a new machine. Much head scratching ensued.
And if you want complete guarantee that this doesn't happen we would still only have ISA plugin cards with non-plug and play dip switches to set the IO adress in which they get addressed.
So yes change doesn't always mean greater AND better AND faster AND easier. Sometimes there is something which turns out worse, either because of an oversight or of deeper technical reasons. Assuming anything is the biggest error here. You need to make a judgement when changing things, testing it explicitedly and incuring the cost of that upfront or taking the risk and maybe fall flat on your nose later. Getting angry afterwards doesn't help your customer nor yourself.