synchronizing junk

[Croll, Andrew [SKY:1V43:EXCH]]

hello all,


I have abit of a problem synchronizing a piece of equipment that I am
attempting to run through a gpib connection (doesn't follow 488.2
though).

The goal is really simple, send a command (which works) and recieve a
responce from the device (just ok or something)

What seems to be happening is the responce is comming too quickly for a
VISA read to catch. this is bad, I need to use visa because it is not
true GPIB 488.2, but I cant seem to correct this problem.

Any insite would be greatly appreciated.

Andrew B. Croll
Optical Specification, Nortel Networks
Ottawa, Canada
andcroll@nortelnetworks.com

[Gorka Larrea]

Well, you could put VISA write in a sequence with three
frames, and implement a delay in the second frame, then
using a sequence local, you could pass the VISA session to
the third frame and there use the VISA read.
But really, it could be a timeout problem, perhaps if you
make a larger timeout using a property node you won't need
any sequences(the problem could be that VISA read times out
before reading).
Hope this helps.


* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful

[Croll, Andrew [SKY:1V43:EXCH]]

Gorka Larrea wrote:

> Well, you could put VISA write in a sequence with three
> frames, and implement a delay in the second frame, then
> using a sequence local, you could pass the VISA session to
> the third frame and there use the VISA read.
> But really, it could be a timeout problem, perhaps if you
> make a larger timeout using a property node you won't need
> any sequences(the problem could be that VISA read times out
> before reading).
> Hope this helps.

No adding more timeing does not help, that is the crazy thing. If I was to recieve, say, a 15 byte responce, it would not matter if timeing was 10s or 10
min, it gives the same problem. However, if I set the Number of bits to read to 15 or less it works. If number of bits to read
is 16 then it gives the
same problem. It is really quite confusing. I shall, however try out your framing idea and see if that will work. I will also try out the ideas put
foreward by Mr. Ahlers. I have also done some reading last night about events and event triggering, it may be that I need to setup some sort of system like
this.

Thanks alot for the help,

Andrew B. Croll

[alkazaa]

Hi Andrew,

Croll, Andrew [SKY:1V43:EXCH] schrieb:

> hello all,
>
> I have abit of a problem synchronizing a piece of equipment that I am
> attempting to run through a gpib connection (doesn't follow 488.2
> though).

So it seems to be some 'old-style' gpib connection...
Buit then still: Even old gpib uses hardware-handshaking

>
>
> The goal is really simple, send a command (which works) and recieve a
> responce from the device (just ok or something)
>
> What seems to be happening is the responce is comming too quickly for a
> VISA read to catch.

with hardware handshaking a 'too quick response' shouldn't happen.

> this is bad, I need to use visa because it is not
> true GPIB 488.2, but I cant seem to correct this problem.

Use VISA because it's not true G
PIB 488.2? What do you mean?
Why don't you use the 'traditional GPIB' routines in LV?

>
>
> Any insite would be greatly appreciated.

If you get it working with the regular GPIB routines it's maybe easier to
find out whay VISA doesn't work (but then you don't need VISA probably).
If you don't get working with regular GPIB, it could really be an 'off all
standards' instrument. Then try to get some GPIB analyzer and monitor the
hardware to find out what's wrong.

>
>
> Andrew B. Croll
> Optical Specification, Nortel Networks
> Ottawa, Canada
> andcroll@nortelnetworks.com

If your equipment is (or ever was) commercially available, tell which model
it is. Maybe somebody else on the list knows it...


good luck


Franz

[Hans]

Had some similar problems with VISA on an instrument with a simple GPIB
implementation.

I sent a command to the instrument and tried to read the response back, but
the VISA read always hang (ie timed ot - returned no data - returned VISA
error). I my case the problem was solved by introdusing a delay of about
100ms between the write and read command. The solution was not very good
because writing a number of commands took a considerable time.....

The instrument suported SRQ and an SRQ was initiated when the instrument had
finishe its action and returned its respons. The solution was to make a
'while loop' between write and read and checking for SRQ and the right bits
in the status register. Use VISA STB function..


Hans Øhra


Croll, Andrew [SKY:1V43:EXCH]
@americasm01.nt.com> wrote in message
news:39187ECE.75A90D8@americasm01.nt.com...
> hello all,
>
>
> I have abit of a problem synchronizing a piece of equipment that I am
> attempting to run through a gpib connection (doesn't follow 488.2
> though).
>
> The goal is really simple, send a command (which works) and recieve a
> responce from the device (just ok or something)
>
> What seems to be happening is the responce is comming too quickly for a
> VISA read to catch. this is bad, I need to use visa because it is not
> true GPIB 488.2, but I cant seem to correct this problem.
>
> Any insite would be greatly appreciated.
>
> Andrew B. Croll
> Optical Specification, Nortel Networks
> Ottawa, Canada
> andcroll@nortelnetworks.com
>

[Croll, Andrew [SKY:1V43:EXCH]]

Hans,

This seems to be a very similar problem to the one that I discussed earlier.
And your solution seems almost identical to the one that I implimented. I
ended up creating a sequece structure after the gpib write. In the sequence
was first a 75ms wait and then a gpib read. This solved my problems as well.

I abandon the VISA stuff and the flexibility that went with it in favor of the
more simplistic gpib stuff. It does work however, and for now that is all that
I need.

Andrew B. Croll
Optical Specification,
Nortel Networks





"Hans �hra" wrote:

> Had some similar problems with VISA on an instrument with a simple GPIB
> implementation.
>
> I sent a command to the instrument and tried to read the response back, but
> the VISA read always hang (ie timed ot - returned no data - returned VISA
> error). I my case the problem was solved by introdusing a delay of about
> 100ms between the write and read command. The solution was not very good
> because writing a number of commands took a considerable time.....
>
> The instrument suported SRQ and an SRQ was initiated when the instrument had
> finishe its action and returned its respons. The solution was to make a
> 'while loop' between write and read and checking for SRQ and the right bits
> in the status register. Use VISA STB function..
>
> Hans �hra
>
> Croll, Andrew [SKY:1V43:EXCH] wrote in message
> news:39187ECE.75A90D8@americasm01.nt.com...
> > hello all,
> >
> >
> > I have abit of a problem synchronizing a piece of equipment that I am
> > attempting to run through a gpib connection (doesn't follow 488.2
> > though).
> >
> > The goal is really simple, send a command (which works) and recieve a
> > responce from the device (just ok or something)
> >
> > What seems to be happening is the responce is comming too quickly for a
> > VISA read to catch. this is bad, I need to use visa because it is not
> > true GPIB 488.2, but I cant seem to correct this problem.
> >
> > Any insite would be greatly appreciated.
> >
> > Andrew B. Croll
> > Optical Specification, Nortel Networks
> > Ottawa, Canada
> > andcroll@nortelnetworks.com
> >

[Kevin_work]

"Croll, Andrew [SKY:1V43:EXCH]" wrote:

> Hans,
>
> This seems to be a very similar problem to the one that I discussed earlier.
> And your solution seems almost identical to the one that I implimented. I
> ended up creating a sequece structure after the gpib write. In the sequence
> was first a 75ms wait and then a gpib read. This solved my problems as well.
>
> I abandon the VISA stuff and the flexibility that went with it in favor of the
> more simplistic gpib stuff. It does work however, and for now that is all that
> I need.
>

I can understand why you may want to abandon VISA, but I dont feel it is really
necessary.
As far as adding a simple wait into a VISA type driver it is just a simple as it
is for a GPIB
solution. I have had to do
this for several pieces of older test gear. What I came
up with
is a subvi that passes the Session and the Error i/o through a sequence that has a
timer
in it. I also pass into the subvi an I32 that is the ms to wait.
This works extremely well and allows me to use VISA as well as getting rid of
sequences
in all but the subvi (there is only one frame there so it is not a big problem).
Now I have a
nice data flow diagram.

There are not a whole lot of differences from 488.1 (original) and 488.2 , most of
them
have to do with standard commands more so than with the actual hardware. On older
488.1
equipment some things like transfer speeds and command termination charaters (EOI,
CR/LF, CR ??)
are different than 488.2.

By the way, if you are using the Easy VIsa VIs you need to realize that NONE of
them close
the session after they are finished. They all say they do but if you look at the
diagram there
is no close session in sight.

Kevin Kent

[Croll, Andrew [SKY:1V43:EXCH]]

> Kevin,

Ya I agree that the using the VISA is probably almost as easy, and there is many
benefits to this over GPIB. I just meant to say that when I was exploring the
problem, I was using the simpler GPIB at the time and since it worked I never
bothered to change it to a better form. Quick, dirty but it does the job and this
will only ever be an internal piece of software so I am probably not going to change
it.

What I had mentioned earlier about 488.2, was also just as you say, this device
doesn't understand any of the "standard" commands. Thus the read and write.

Thanks for the input from everyone, with all this help I have solved my problem.

Andrew B. Croll
Optical Specification
Nortel Networks