No device response even with open serial port under linux -- normal behavior under Windows

[Sputnikrent]

Hi Thomas,

Thanks for the info. I'm currently looking into this right now and will let you know what I find out.

[Sputnikrent]

Hey Thomas,

So I spoke to R&D and they came back with this info:

NI-VISA makes use of the only way to get errors reported back on POSIX, and that is to use flags INPCK and PARMRK.  These flags enable the checking for the FF control code byte in the buffer, and when they find FF, another byte gets added to the appearance of the buffer because there appears to be an error report included (directly after the FF byte. Having it twice in the buffer is what is causing the appearance of two extra bytes. 

I have attached with this reply the screenshot that shows this.

Will you be able to remove the FF in your data? (FF hex =  255 decimal).  We apologize for the inconvenience but we would like to keep our error reporting on Linux. This is something that R&D has been aware of, and this issue has come up before.

Here is a link to a site with an explanation: http://digilander.libero.it/robang/rubrica/serial.htm (search for INPCK or PARMRK)

Here's another site that explains the byte increase specifically, in the PARMRK section.  They mention 0377, which is just octal for 0xFF.
http://www.delorie.com/gnu/docs/glibc/libc_362.html

Please let me know if you have any other questions, thanks!

[Fusselpelusa]

Thanks for the explanation. There is still somthing I don't understand:
If there are 17 physicl bytes waiting at the port to be read by VISA, why does VISA add to these bytes 2 more? I understand that is reads twice FF and hence thinks, there is an error code hidden in the code. But if only 17 bytes are waiting why does it add two bytes? Whay couldn't the error code be within these 17 bytes? Hm there is something that I still don't get. If there is a real error (after the FF), this would also show up as physical byte at teh port, and hence already be counted?
Thomas

[Sputnikrent]

Hi Thomas,

I'm looking into this right now to clarify things so that the information will be clear. I will let you know what I find, thanks!

[rodmangon]

Hi everyone,

I was reading the whole conversation and I think you could help me. I am using the same connector (Silicon Labs CP210x USB to UART Bridge) to connect my PC (USB) with a motor controller (RS485), knowing that this connector was provided by the motor controller manufacturer (NANOTEC). This manufacturer also has a software (NANOPRO) to know if this communication and the motor controller (SMCI36 from NANOTEC) are working properly, and it is. 

But the problem appears when I want to program the same in LabView, and I think the problem is this connector, because a few months ago i programmed another motor controller (SMCI33 from NANOTEC) with Labview, using an USB connector to the PC, and there was no problem. That´s why i think now the problem is this connector. 

I tried to use the examples that LabView offer ("Basic Serial Write and Read.vi", "Advanced Serial Write and Read.vi",...). In some of them i didnt get any error, but the information wasn´t sent because the motor didn´t start, and in others, I got a timeout error (-1073807339). Finally i tried to programm it by myself ("Initialisation (SubVI).vi" attached file). With this one, i didnt get any error either, but the information (writing the type of motor, #1:CL_motor_type=1\r ) is not sent. As you can see, the Terminal Character is \r.

I dont know what could be the problem. If you have any idea, please, let me know it. 

Thank you so much.

[Dennis_Knutson]

duplicate post

Asking the exact same question multiple times is just irritating.