Communication via rs232 without instument driver

[Kimos97]

Hello Guys,

I am a new user of Labview and I am trying to communicate with an ELP/SL DC load in order to conduct an experiment and I am using an RS232 connection.

This is the manual of the instrument:

https://www.et-system.de/fileadmin/user_upload/Manuals_Software/ELP_SLM_1002_Operating_Manual.pdf

I have set the DIP switch correctly, I am using a null-modem cable and I am trying to do the simplest thing: to send the command ID and to receive the answer. As you can see on page 30 of the manual the command is supported from the instrument however I don't get any results. (To be clear, I just write "ID" in the write buffer, without quotation marks!)

I use the "bytes at port" in order to avoid the BFFF0015 error (because I get no answers), but I have put a delay in order to avoid any trouble I have read for this command. I want also to point out that except the Visa-driver, serial driver, etc. I haven't used any specific driver for this instrument because I can't find one.

Can anyone suggest to me any solutions?

[AeroSoul]

I can't open the VI, could you save it for version 2019?

How are your DIP switches set?

Are you sending a termination character? (CR or LF)

[Kimos97]

I have switch #8 on and all the others off.

I have set the termination character at the start of my program as you will see. I have tried both defining none termination character and typing it manually with the command and in the visa configuration.

And I am attaching the vi for LabVIEW 2019

[AeroSoul]

Try this

[RTSLVU]

This video should answer a lot of your questions: VIWeek 2020/Proper way to communicate over serial

As far a instrument drivers... The vast majority of them are nothing more than the instruments SCPI commands wrapped up in a set of VI's saving you a few hours of "grunt work".  But the nice thing is they often come with an example or two to get you started.

[Kimos97]

Thank you for the suggestion (and sorry for the late answer but as a new member I can post only 2 times in the first 24 hours).

Unfortunately, this configuration end up in BFFF0015 error (time expiration) because there is nothing received for reading.

I would like to say that this device works with SCPI commands and I have tested the communication via the NI Max control panel where the same error occurs. I have tested my cable and my USB converter for sending the commands and the commands are seemed to be sent correctly. On page 25 of the manual, it is clear that the termination character that I use is correct. The only thing that I cannot deeply understand is the standby functions on page 27 ( I don't know if I should send a standby command first, however, the combinations that I tried with standby commands didn't work either). After that,  I haven't any other ideas of what should I test in order to debug my problem.

[Mark_Yedinak]

Based on a quick look at the manual you need to first configure the operational mode before sending it values to control the output. Which mode depends on how you are planning to use the instrument. This looks like a very simple protocol. Also, when using a serial port it is generally best to configure and open the port and the beginning of application and close it at the end. You don't want to open/close every time you communicate with the instrument. It also appears that this instrument does not reply to every command. Therefore this isn't much of a surprise that you are getting a timeout on your read. You should use one of the query (STATUS) commands or the DI command to see the state of the instrument.

[Mark_Yedinak]

Reply to a PM asking for more clarification:

So to confirm, on the dip switch you only have switch 8 set meaning you are configuring the device for RS-232 using 9600 BAUD. You are running this VI by itself or is it a subVI being called from another VI? I would change the mode on the ASRL End Out to "None" and explicitly include the Linefeed (\n) to my commands. So, the string you are sending to the device to check the status is "DI\n" (not including the quotes). This would be the value in your write buffer with the mode set to "'\' Codes Display".

I would not use Bytes at Port to determine how many bytes you should read. Use the termination character. Did you probe the output of Bytes at Port to see if there is a value? If it is 0 you will not read anything even if data is there. I would simply set the bytes to read to a number larger than your largest size of a data response. When the instrument sends the response with the termination character the read operation will complete.

If this VI is the entirety of your application (doubtful since it doesn't do much) then the open/close is appropriate. If this is a utility VI for sending/receiving commands then it should not include the open close. That should only be done once in your application at the beginning and end of a complete session. For example, if your application is a basic state machine the open would be in the initialize state and the close would be in the exit state. All other states would simply use the current connection that was established in the initialize state.

[Kimos97]

Thank you very much for the clarification,

This VI is just my first attempt to communicate with the instrument, so for now, this is it that's why I open and I close the port. The problem is that I tried the straight command with the termination character (and I defined ASRL End Out to "None") and still, there is no answer. I have also connected with 3 other instruments in my lab and they worked fine with the same cable and USB adapter so I know that it is not a hardware problem from my side.

This VI is super simple and I always start with this in order to test if the communication is ok with my instrument. I have tried many many ways to send this command but there is no answer. Is there any other way to check if my instrument works correctly (I have tried the DI command that is for the errors but no answer as well, I am asking for a physical test or something like that)?

I have also asked the company for the instrument's troubleshooting maybe in few days I will have a reply.

[Kimos97]

Finally, it was indeed a defected communication card. So the problem was in the hardware and not in the software. Thanks everyone for the help and the advices!