Tony:
It looks like your instrument returns some peculiar EOL terminators:
<0a><0d><00><0a><0a>
which is a linefeed, carriage return, a null byte and two more linefeeds.
These last two are probably what you describe as 'the double space
between commands in telnet'. You can possibly use 'LF LF' as your input
terminator, and swallow up the 'LF CR \0' using "%*c" in your protocol.
I'm not sure what effect a null byte has on processing and terminating
input.
I will guess that your sample output was using 'LF' as the input
terminator. This would terminate reading on the first LF, and then leave
the CR - 00 - LF -LF remaining in the stream for processing.
Alternatively, you migh be able to use multiple 'in' commands in your
protocols, each one swallowing up more and more of the line terminator.
It would be so much simpler if instruments could just get these things
right in the first place.
--- rod.
On 10/25/2012 04:44 PM, Anthony Andrews wrote:
Thanks for the advice!
The echo command was causing those problems.
To solve that, I made two records and two protocols to set SB (echo) and
SM (command prompt length) to 0.
So, now I can get the current and voltage to change slowly.
However, in MEDM I have to hit enter quite a lot to get the voltage to
change and the current doesn't want to change very fast either.
I also get another kind of mismatch error in the output which I think is
a possible cause for the current and voltage changing slowly.
############################################################################
## EPICS R3.14.12.2 $Date: Mon 2011-12-12 14:09:32 -0600$
## EPICS Base built Oct 17 2012
############################################################################
2012/10/25 16:46:37.111 10.1.1.1:4008 <http://10.1.1.1:4008> write 3
SR\n
2012/10/25 16:46:37.613 10.1.1.1:4008 <http://10.1.1.1:4008> write 4
SB0\r
2012/10/25 16:46:37.613 10.1.1.1:4008 <http://10.1.1.1:4008> write 9
PV38.000\n
iocRun: All initialization complete
###########################################################################
## Start any sequence programs
#seq sncxxx,"user=tonyHost"
epics> 2012/10/25 16:46:38.112 10.1.1.1:4008 <http://10.1.1.1:4008> write 3
MC\n
2012/10/25 16:46:38.685 10.1.1.1:4008 <http://10.1.1.1:4008> read 10
0.004\r\000\n\n>
2012/10/25 16:46:38.685 10.1.1.1:4008 <http://10.1.1.1:4008> write 4
SM0\r
2012/10/25 16:46:38.685 10.1.1.1:4008 <http://10.1.1.1:4008> write 9
PC 0.000\n
2012/10/25 16:46:38.685 10.1.1.1:4008 <http://10.1.1.1:4008> write 3
MV\n
2012/10/25 16:46:38.702 10.1.1.1:4008 <http://10.1.1.1:4008> read 5
\r\000\n\n>
2012/10/25 16:46:38.702 P8 LamEMS:ADDR:VOLT_M: Input "<0d><00>" does not
match format %6f
2012/10/25 16:46:39.112 10.1.1.1:4008 <http://10.1.1.1:4008> write 3
MC\n
2012/10/25 16:46:39.684 10.1.1.1:4008 <http://10.1.1.1:4008> read 10
0.004\r\000\n\n>
I've also attached a screenshot of telnet, and updated protocol and
database file.
I think that the error here may have something to do with the double
space between commands in telnet, but, I'm not sure.
I'm also not sure what <0d><00> means here.
So far I've tried different terminators, terminators in multiple places
(inside protocols and at the top), and I've tried to represent the
"\r\000\n\n>" at the end of each read inside of the protocol.
But, I can't seem to figure it out.
I think that if I can fix this error, the current and voltage may change
a bit faster as well.
If anyone has any advice on how to get rid of these last error it would
be very helpful.
Thank you.
On Wed, Oct 24, 2012 at 7:05 AM, Rod Nussbaumer <[email protected]
<mailto:[email protected]>> wrote:
Tony:
It looks like the power supply echoes the commands that are sent to
it. You will need to craft your protocol(s) to read these echoed
commands, or there may be a way to turn off the echoes.
Rod Nussbaumer
ISAC Controls, TRIUMF
Vancouver, Canada
On 10/23/2012 05:17 PM, Anthony Andrews wrote:
##############################__##############################__###############
## Start any sequence programs
#seq sncxxx,"user=tonyHost"
epics> 2012/10/23 18:05:13.924 xxx.yyy.zzz.aaa:4008 write 3
MC\n
2012/10/23 18:05:13.936 xxx.yyy.zzz.aaa:4008 read 5
MC\n\r\000
2012/10/23 18:05:13.936 P8 LamEMS:ADDR:CURR_M: Input "MC"
mismatch after
0 bytes
2012/10/23 18:05:13.936 P8 LamEMS:ADDR:CURR_M: got "MC" where
"Current =
" was expected
2012/10/23 18:05:13.936 xxx.yyy.zzz.aaa:4008 write 3
MV\n
- Replies:
- Re: Lambda EMS mismatch errors Eric Norum
- References:
- Lambda EMS mismatch errors Anthony Andrews
- Re: Lambda EMS mismatch errors Rod Nussbaumer
- Re: Lambda EMS mismatch errors Anthony Andrews
- Navigate by Date:
- Prev:
Re: Lambda EMS mismatch errors Anthony Andrews
- Next:
Re: Lambda EMS mismatch errors Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Lambda EMS mismatch errors Anthony Andrews
- Next:
Re: Lambda EMS mismatch errors Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|