0

Metcal 9.0 and CSA 803A program, Time Out

Ok, so new issue with Metcal 9.0, and Procedures written in 7.3x.  I have a CSA803A that I am calibrating with an existing Metcal program.

 

I am creating a time out error at this line in my code

15.014  IEEE         MEAN?[D100][I]

So I did some back tracking, and spying the bus.  What I see is that the command is initiating, and receiving.

 

532.  Send(1, 0x000D, "MEAN? ", 6 (0x6), DABend (0x02))

533.  Receive(1, 0x000D, "MEAN 5.5908E-...", 4096 (0x1000), 0xA)

534.  RcvRespMsg(1, "", 4096 (0x1000), 0xA)

 

But it Times-Out at the “ [I] “ part of the line. It never sends the command on to Metcal. 

 

Has anyone had any success reading from the CSA803A or any of its like items? 

 

Have you had an issue where the commands you send to a UUT are good, or have been good in the past, but no long with the Upgraded version of Metcal?

It appears to be a communication issue between Metcal and the NI card. When trying to read from the UUT.  I have no issue talking to the UUT.  I have checked the bus to make sure there are no other units on or attached to the GPIB1 bus.  That might cause this issue. 

Still working on this one, but if you have any insights I would greatly appreciate the help. 

 

Ken

23 comments

Date Votes
0
Avatar
Michael Johnston

Maybe it's looking for a terminator? Try adding a [10] between the command and the [I] part.

I would also try setting the timeout to something higher to make sure it's not a speed problem. Just add [T5000] to the end of the line.

0
Avatar
Michael Schwartz

We developed these procedures for Intel a long time ago, so my memory is a little fuzzy.    But I do remember they have to be terminiated correctly and you may have issues with the SRQ on power up.. We told many customes who didn't have a two card MET/CAL system to pull pin 10 on the GPIB cable and always connect that cable to the UUT.   SQR's with the highend Tektronix scopes was usually where we had the problems. 

If you would like to talk to me offline my email address is MSchwartz@CalLabSolutions.com 

Mike

0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]

Thank you for the suggestions

I tired using the [10] and the  [13] Terminators, No luck

The [T5000] did not help either.  

 

Still getting the Time Out at the line [I] = read number from current address, store in MEM

 

Ken

0
Avatar
Nickolas Short

I had a similar issue when calibrating power supplies.

Our old setup was windows xp with MC7 and it worked fine.

We upgraded the computer to a faster one, still running MC7. At this point, MC was running faster than it was before.

This caused an issue where MC sent a command to our RMS Voltmeter before it had recovered from the last one.

To solve the issue (much to the chagrin of my wife, who is a legitimate programmer) I used delays between readings to allow the RMS Voltmeter to "catch up".

Maybe try putting a WAIT command before the IEEE FSC? WAIT [D2000] might do it :)

0
Avatar
Michael Johnston

Only other thing I'm seeing at the moment is to move the delay to after the I. I just pulled up a copy of the procedure we bought for this from intercal and here's what the reading lines look like:

 13.008  IEEE         MEAS MEAN?[I][D1999]

0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]

I gave the line a try but no luck on my end.  I am wondering if there is a setup terminator further up the code that is setting the scope up in a particular way.  

I have tried different ones at different points in the code, just not seeing any positive results. 

Everything I see points to the [I]

[I] read number from current address, store in MEM 

It is not passing the information back to Metcal, or is getting stuck some how.   It is just plain wierd!

 

Ken

0
Avatar
Nickolas Short

Give my idea below a try. It sounds to me like an instrument speed vs computer speed problem. the CSA 803 was made at least as early as 1993. It might just not be up to par, responsiveness-wise.

0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]
My apologies Nick, I should have written sooner.  Still testing some of them out.
 
 
I agree with you, this UUT is old and slow.  I did try using a series of time outs [D2000] to slow things down.  But I hate to say it, they did not work either.  
 
 
So what I have been doing is spying the bus while the program is running, checking to see what commands are running and determining where it stop, or hangs up.  The program always stops at the [I].  Where the command is read in put into MEM. 
 
 
So the last thing I have been playing around with is the EOI ON|OFF] command.  I had some initial success with these, but in the end even they fail to continue to work.  
 
 
What makes this so frustrating is the program worked in our previous version of Metcal 7.3x.  Only when we moved to the newest version of Metcal, did we start having some series issues with our existing programs. 

 

0
Avatar
Nickolas Short

Hmm...I'll try and do a little digging myself to see if I can come up with any more suggestions :)

0
Avatar
david morgan

have you tried using [I$] in place of [I]?

0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]

 

Yes I tried that one as well. 

 

0
Avatar
Michael Schwartz

Ken, 

Did this code work in the previous version of MET/CAL?

0
Avatar
Nickolas Short

Have you tried the TERM command for the IEEE FSC?

If you haven't, play around with different types:

IEEE     [TERM CR]

or

IEEE     [TERM LF]

0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]

 

In the orginal code  " IEEE  [TERM LF]" is used.  I tried using [TERM CR], but with no success.

0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]

 

Yes,   we upgraded from Metcal 7.3x to  9.0.  The code has worked for a very long time.

0
Avatar
Michael Schwartz

It is common for older instruments to use CR or LF to terminate communications.  

I am guessing the CSA-803A did not change its terminator if it worked with [TERM LF] then that is the termination char.  There is the possibility that it ends with CR & LF, but LF is the last char sent, so you should not get a time out. 

You can try adding [S 9] to the IEEE Line, this is an old trick to delay the byte per byte data that is sent.  

Also, check that you have no more than 2 GPIB cables connected to any device.  And are using the shortest possible cables. 

But in the end, my guess is this is an issue with MET/CAL 9.0, something you will not be able to resolve.  If it worked in 7.3x and the firmware of the CSA-803A has not changed in years.  I always look back to the last thing that changed.

You can contact me offline, I have a few more tricks, but I am also happily running a 7.x system.  

Mike

 

0
Avatar
Nickolas Short

It's possible that there was a change in MET/CAL with what it expects for EOM from equipment.

I found this (see attached pictures) in the CSA803A user manual:

It may be that you have the CSA set to EOI (end or identify) and not EOI/LF.

See the attached images and try setting it to EOI/LF, if it isn't already.

Attachment not imported: csa2.jpg
0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]

This is the answer.  The CSA was indeed set for EOI, and NOT EOI/LF.  

Once I reset the GPIB configuration it started responding as expected. 

I have inserted a Disclaimer in my code to have the operator check this configuration before even attempting the procedure.  That should solve this effort for those that might experience it in the future

Thank you for your help, it is greatly appreciated!

 Ken. 

0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]

Mike, 

thank you for your help it was greatly appreciated.  Nick, found the answer and I was able to get the program back up and running. 

Ken

0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]

I just want to take a moment to say thank you to everyone! 

I was struggling with this issue that in the end turned out to be something very simple.  

Simple only in the sense that it took one button selection to correct, but not simple in the fact that I did not know where to look.

Thank you all for taken the time out of your day to think about this problem and work towards a solution.  I tried everything that was suggested.  I took no answer for granted.

This is what collaboration is all about, and I thank you.

 

Ken

0
Avatar
Michael Schwartz

That is odd... EOI should have terminated the communications.  EOI if I remember correctly is a hardwired pin on the GPIB.  It tells the controller-in-charge I am done talking.

What version of the NI drivers are you running?

Mike 

 

0
Avatar
Nickolas Short

Glad I could help :)

Quite often, the answer is the easiest thing.

Being highly technical, we tend to overly complicate things :)

0
Avatar
Teague, Kenneth M. (JSC-EA5)[ROHMANN SERVICES, INC]

Mike, 

Here is the list:

 

  • LabVIEW Run-Time 2009 SP1
  • LabWindows/CVI Run-Time 2009
  • Measurement 8: Automation Explorer 4.7.1
  • NI PXI Platform Services 2.5.6
  • NI Spy 2.7.2
  • NI System Configuration 1.1.1
  • NI-488.2 2.80
  • Nl-PAL 2.5.4
  • NI-VISA 5.0
  • NI-VISA Runtime 5.0
 
Ken

Please sign in to leave a comment.