I am trying to communicate with an old Sorensen DCS power supply (DCS100-12) via RS232. It has the M9 option and the manual is attached. I am using a RJ11 to DB9 cable as mentioned in the section 2.4.
Before going to a Labview VI, I am first trying to communicate using the VISA Test Panel. I am using the following parameters as mentioned in the manual :
Baud rate : 19200
Data Bits : 8
Stop Bits : 1
Parity : None
If I start the power supply and query "*IDN?\r\n" I get both the answer and a timeout error (see image below). The next query will always timeout (even *IDN? ).
I have tried a lot of different setting with no success. In the other hand I tried to use a GPIB to USB adapter from another device and it works fine.
Solved! Go to Solution.
Thanks for your help,
I have also tried the \r and \n alone without success.
I guess I will have to buy another GPIB to USB adapter.
This power supply is unknown to me, so I can't speak from experience.
However, after spending a few minutes to read the instruction manual, I wonder if the problem does not come from the use of the IDN? command (instead of ID?).
I tried the ID? command without success as well (with the different termination characters mentioned above). It timeout as any other read command.
As I understand from the manual, M9A and SCPI are just two different languages but the HW setup is the same for both of them (cf Section 2).
I could imagine that the issue comes from the wiring, but I still receive an answer via the first IDN? command just after the power supply startup.
I wonder if this can come from the VISA Test Panel. Is there another simple tool that can perform the same kind of tests ?
Try entering *STB?\n or *CLS\n prior to sending the *IDN?\n queries. It may be that their is a status message awaiting.
I tried both command with \n and \r\n as termination character.
Similarly to the *IDN?\r\n command, the *STB?\r\n works only one time after the restart of the power supply and it send me both a timeout error and the answer "68\r". The *CLS\r\n timeout the first time (even after a startup) and the next *IDN?\r\n timeout as well.
The response to *STB? gives us some insight as to what the issue may be.
The response of 68 = 64 + 4 as the status byte is a binary representation which is described on page 3-2 of the manual.
(64) ==> It seems that you are configured with the Service Request = ON. This could be due to a couple of things.
1) Do you have DIP switches on the back of the supply? If so, make sure that the first 3 (MSB) switches are set according to figure 2.3. (This device is responding as if the 2nd switch is in the ON position)
2) *SRE is set in software. Try writing, "*SRE0\n" to the device.
(4) ==> Implies that there is an error message waiting in the buffer. Enter the query, "SYST:ERR?\n" to find the response and compare versus the SCPI Error Codes which begins on page 3-4.
Thanks a lot for your explanation on the binary representation.
I don't get the link between 64 and the service request. On page 7-3 the bit n.7 in the SCPI Status Byte correspond to the "Operation Status Flag".
(64) Service request
1) The 3 DIP switches are set up as described on the Figure 2-1 (for DCS Power supplies).
2) I tried the "*SRE0\n" command but it doesn't change anything. I also tried to query "*SRE?\r\n" after a startup and got "0\r". So I guess that is not the issue.
(4) Error message
I have restarted again the power supply and query "SYST:ERR?\n". I got the following error:
The manual mention :
201 - Unexpected warm boot
This error means that the M9 GPIB-side processor experienced a warm boot that was unexpected, and it may indicate an internal crash of the M9 processor.
I don't think this comes from a HW issue as I tried with three differents DCS power supplies and got the same error. Moreover the power supplies are working using the GPIB to USB module.