LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

problem acquiring data from Beckhoff Buscoupler with Serial port

Maybe someone can help me with the following problem. I'm using a Beckhoff
buscoupler to read out an analog current input. With an pid controller (with
the current as input) I control an output. Most of the times this works without
any problems. But sometimes the Beckhoff does not give me any data (only
zeros), so the pid loop gets crazy and the voltage output becomes very large.
The problem mostly occures when I start an other program on the NT machine.
But it sometimes also occures when I'm not doing anything else. Does anyone
know what could be the problem, and maybe have a solution for me.

Any help is really appreciated.

With kind regards,

Joost de Jonge
0 Kudos
Message 1 of 5
(3,348 Views)
Joost de Jonge wrote in message
news:39ae4aca@newsgroups.ni.com...
>
> Maybe someone can help me with the following problem. I'm using a Beckhoff
> buscoupler to read out an analog current input. With an pid controller
(with
> the current as input) I control an output. Most of the times this works
without
> any problems. But sometimes the Beckhoff does not give me any data (only
> zeros), so the pid loop gets crazy and the voltage output becomes very
large.
> The problem mostly occures when I start an other program on the NT
machine.
> But it sometimes also occures when I'm not doing anything else. Does
anyone
> know what could be the problem, and maybe have a solution for me.

Are you checking the error output of your serial read
and write functions?

Are you using handshaking on the serial transfers?

Have you checked the conversation with the instrument to make sure you're
not getting into a situation where the instrument is returning errors across
the serial line that you're not handling and clearing?

As a bodge, you could add a simple routine that, if the returned value is
null, simply does not run the PID function and leaves the output voltage as
it is. You may run into instability problems because of variable time delays
between execution of the PID, but since the time constant of your system
(response of a current to a voltage change) is likely to be much less than
the time between PID iterations, you can probably get away with faking the
time term of the PID, so that regardless of the real times between calls the
interval time used in the formulae is always the same.
0 Kudos
Message 2 of 5
(3,348 Views)
In article <8ollrf$btp$1@sponge.lancs.ac.uk>,
"Craig Graham" wrote:
>
> Joost de Jonge wrote in message
> news:39ae4aca@newsgroups.ni.com...
> >
> > Maybe someone can help me with the following problem. I'm using a
Beckhoff
> > buscoupler to read out an analog current input. With an pid
controller
> (with
> > the current as input) I control an output. Most of the times this
works
> without
> > any problems. But sometimes the Beckhoff does not give me any data
(only
> > zeros), so the pid loop gets crazy and the voltage output becomes
very
> large.
> > The problem mostly occures when I start an other program on the NT
> machine.
> > But it sometimes also occures when I'm not doing anything else. Does
> anyone
> > know what could be the problem, and maybe have a solution for me.
>
> Are you checking the error output of your serial read and write
functions?
>
> Are you using handshaking on the serial transfers?
>
> Have you checked the conversation with the instrument to make sure
you're
> not getting into a situation where the instrument is returning errors
across
> the serial line that you're not handling and clearing?
>
> As a bodge, you could add a simple routine that, if the returned
value is
> null, simply does not run the PID function and leaves the output
voltage as
> it is. You may run into instability problems because of variable time
delays
> between execution of the PID, but since the time constant of your
system
> (response of a current to a voltage change) is likely to be much less
than
> the time between PID iterations, you can probably get away with
faking the
> time term of the PID, so that regardless of the real times between
calls the
> interval time used in the formulae is always the same.
>
>


Thanks for your answer.

I'm not using the standard serial port command from Labview. We are
using some special software which is provided by beckhoff. I don't know
if this software is using handshaking. Normally I can read errors with
the beckhoff software, but at the moment the error occures also the
error byte is zero.

In a reply from beckhoff, they could only tell me that their software
is synchron.

Hmm, not running the pid routine is no option... We want to measure
very accurate, and when the pid controller is not working anymore we
are not able to control the flow (which we are controlling with the
pid).

Strange thing is, we first had a pascal (dos) program which works
without any beckhoff related problems. But using Labview only gives us
new problems.....

With kind regards,

Joost de Jonge


Sent via Deja.com http://www.deja.com/
Before you buy.
0 Kudos
Message 3 of 5
(3,348 Views)
wrote in message
news:8ooblo$h9v$1@nnrp1.deja.com...
>
> I'm not using the standard serial port command from Labview. We are
> using some special software which is provided by beckhoff. I don't know
> if this software is using handshaking. Normally I can read errors with
> the beckhoff software, but at the moment the error occures also the
> error byte is zero.
>
> In a reply from beckhoff, they could only tell me that their software
> is synchron.
>
> Hmm, not running the pid routine is no option... We want to measure
> very accurate, and when the pid controller is not working anymore we
> are not able to control the flow (which we are controlling with the
> pid).
>
> Strange thing is, we first had a pascal (dos) program which works
> without any beckhoff related problems. But using Labview only gives us
> new problems.....

Does the DOS program work under a DOS box running in under NT, or do you run
it from a DOS-only boot? It's possible the proprietary driver software is
giving problems under NT. If you're only using this to make voltage
measurements, can you not write a simple Labview VI that will perform the
serial operation from within Labview? Such an approach is much more
transparent and easier to debug- it's quite difficult, for example, to see
the exact conversation between PC and instrument if you don't have direct
control of the software that owns the serial port.

I'm not familiar with the Beckhoff software you mention. How is it being
controlled from within Labview? Is it a DLL?

If Beckhoff can't even tell you enough about the software to determine
whether it uses handshaking or not, I'd definitely consider writing a custom
driver and figuring out the serial settings by trial and error, after
checking they're not specified in the manual. Getting the protocol is likely
to be a challenge, though, if they aren't able or willing to supply it-
Alphatronics do a "virtual port" package that lets you capture data going
out to a port, but it's unidirectional which limits the usefulness. What I'd
actually be inclined to do is grab another PC with two serial ports and set
up a simple Labview vi to link the ports together, capturing the data both
ways as it passes through. You then connect the "snoop" PC between the
instrument and the DAQ machine and see what's going on- this may also be
useful in seeing what happens immediately before the failure- the problem
may be on the access before the one that fails, for instance.
0 Kudos
Message 5 of 5
(3,344 Views)
In article <8ollrf$btp$1@sponge.lancs.ac.uk>,
"Craig Graham" wrote:
>
> Joost de Jonge wrote in message
> news:39ae4aca@newsgroups.ni.com...
> >
> > Maybe someone can help me with the following problem. I'm using a
Beckhoff
> > buscoupler to read out an analog current input. With an pid
controller
> (with
> > the current as input) I control an output. Most of the times this
works
> without
> > any problems. But sometimes the Beckhoff does not give me any data
(only
> > zeros), so the pid loop gets crazy and the voltage output becomes
very
> large.
> > The problem mostly occures when I start an other program on the NT
> machine.
> > But it sometimes also occures when I'm not doing anything else. Does
> anyone
> > know what could be the problem, and maybe have a solution for me.
>
> Are you checking the error output of your serial read and write
functions?
>
> Are you using handshaking on the serial transfers?
>
> Have you checked the conversation with the instrument to make sure
you're
> not getting into a situation where the instrument is returning errors
across
> the serial line that you're not handling and clearing?
>
> As a bodge, you could add a simple routine that, if the returned
value is
> null, simply does not run the PID function and leaves the output
voltage as
> it is. You may run into instability problems because of variable time
delays
> between execution of the PID, but since the time constant of your
system
> (response of a current to a voltage change) is likely to be much less
than
> the time between PID iterations, you can probably get away with
faking the
> time term of the PID, so that regardless of the real times between
calls the
> interval time used in the formulae is always the same.
>
>


Thanks for your answer.

I'm not using the standard serial port command from Labview. We are
using some special software which is provided by beckhoff. I don't know
if this software is using handshaking. Normally I can read errors with
the beckhoff software, but at the moment the error occures also the
error byte is zero.

In a reply from beckhoff, they could only tell me that their software
is synchron.

Hmm, not running the pid routine is no option... We want to measure
very accurate, and when the pid controller is not working anymore we
are not able to control the flow (which we are controlling with the
pid).

Strange thing is, we first had a pascal (dos) program which works
without any beckhoff related problems. But using Labview only gives us
new problems.....

With kind regards,

Joost de Jonge


Sent via Deja.com http://www.deja.com/
Before you buy.
Message 4 of 5
(3,346 Views)