I was too precipitated by saying everything was OK. I tried to acquire the HArdcopied image towards the end of the day, and - darn - it stopped working. I mean no error at the StreamDevice side. But when I run the python script I mentioned earlier to strip off the image header and update the waveform - I get an error from the Image module that it's not valid image data :(((
I don't even know how to check whether Stream Device has worked successfully or not (all data read?)...
Today I thought I had completely ported the python script from the IOC
machine to the client's (as it's not a good idea to always SSH to the
server and run script from there). ANd you know what is the point in running Python scripts when we are using EPICS. And now , what a bummer!
Need help.
Pavel
On Thu, May 3, 2012 at 4:49 PM, Pavel Masloff <[email protected]> wrote:
Hello Dirk!
Thanks for the method. It works only when I get the whole file (%1r). BTW, are you sure it should be %1r, not %0r? we are using unsigned char.
record(waveform, "$(P)$(R)filez") {
field(DTYP, "stream") field(SCAN, "Passive")
field(INP, "@devTPS20xx.proto get_picture $(PORT) $(A)") field(NELM, "1500000")
field(FTVL, "UCHAR") }
Terminator="\n";
get_picture { InTerminator=""; # we receive binary data
ReplyTimeout = 5000; ReadTimeout = 30000;
out "HARDCOPY START"; #in "%*36r"; # skip 36 bytes
in "%0r"; # read all bytes into waveform }
So, as it's a bmp (bmp version: bmp_bm3; bmp compression: bmp_rle) file sitting in the waveform, I have to use a Python script on the client machine (the server is the IOC) to strip off the header and refresh the waveform with pure image data:
from epics import PV import Image
import StringIO import os, sys
chan = PV ('TPS2024B:filez') data = "">
sdata = ''.join(chr(x) for x in data) sfile = StringIO.StringIO(sdata)
im = Image.open(sfile)
im.show()
And another thing I have noticed. This image is very greyish, I hardly see anything on it. So I go on with saving it into gif and copy it to the waveform record (now pure image data):
im.save('c:\hello.gif','GIF')
iM = Image.open ('c:\hello.gif') chan.put(iM.getdata())
In CSS BOY then I add a color map and it all works :)
I wonder, why it doesn't work with "in "%*36r"; # skip 36 bytes". It says:
L1 TPS2024B:filez: 10574 bytes surplus input "<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>..."
L1 TPS2024B:filez: after 36 bytes "...<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>"
On Thu, May 3, 2012 at 1:13 PM, Dirk Zimoch <[email protected]> wrote:
Hello Pavel,
Use a CHAR or UCHAR waveform with NELM large enough for the file, empty InTerminator, %1r converter.
Maybe MaxInput=<size of file> to avoid using timeout as a terminator. The file you sent me has 14940 bytes. Is this always the case?
record (waveform, "$(PICTURE)") {
field (FTVL, "UCHAR")
field (NELM, "14940")
field (DTYP, "stream")
field (INP, "@protocolfile get_picture asynport")
}
Terminator="\n";
get_picture {
InTerminator=""; # we receive binary data
MaxInput=14940; # number of bytes to read
out ":HARDCOPY:FORMAT PNG;PALETTE NORMAL;PORT RS232;"
"LAYOUT PORTRAIT;PREVIEW 0;INKSAVER 0;COMPRESSION 0";
out "HARDCOPY START";
in "%1r"; # read all bytes into waveform
}
This will put the fill file into the waveform. To display the waveform is a completely different issue.
You can as well cut of header information:
...
in "%*36r"; # skip 36 bytes
in "%1r"; # read remaining bytes into waveform
I found a 1 at byte 30 of your file. According to Wikipedia, that means that the image is compressed. Even though the setting was "COMPRESSION 0". Maybe the file and the settings above do not match.
With compression things are more difficult because the size varies. In that case make NELM large enough for the largest possible image and do not use MaxInput. Play with ReadTimeout to get minimal delay but without losing data. The file size is encoded in the header, but at the moment, StreamDevice cannot use this information to change the number of bytes read dynamically.
Dirk
Pavel Masloff wrote:
Hello again,
As I mentioned earlier we are running a series of experiments with our high current switches. I have written simple support ("...with a little help from my friend" Dirk Zimoch) for the Tektronix TPS2000 over RS232 using StreamDevice and ASYN, so now I can remotely arm the scopes, set its properties, save waveforms on to the CF card, etc. But...
In order to not run back and forth and see if everything went OK (which is rather tiresome and time consuming), we need a confirmation from the scopes. I don't want to deal with the implementation of the waveform records for now, all I have got so far is that I save them on the flash card.
As such a confirmation I see transferring the BMP (or PNG) image from the scope (sort of Print screen) on to the operator PC somehow.
There is a special SCPI command "Hardcopy start". Which mimics the Print button on the scope's front panel. I have tried to transfer a BMP file via Hyperterminal (and Python script) and it worked out well (more or less).
How could this be ported to the EPICS database from the IOC and client standpoint, so an operator could see the oscillogram on the screen and decide whether the experiment went well, so she will save the waveforms and move on to the next experiment?
The image file is maximum ~ 46Kb (20Kb on average).
Any thoughts?
--
Best regards,
Pavel Maslov, MS
Controls Engineer at Pulsed power Lab
Efremov Institute for Electro-Physical Apparatus
St. Petersburg, Russia
Mobile: +7 (951) 672 22 19
Landline: +7 (812) 461 01 01
-- Best regards,
Pavel Maslov, MS Controls Engineer at Pulsed power Lab Efremov Institute for Electro-Physical Apparatus
St. Petersburg, Russia
Mobile: +7 (951) 672 22 19
Landline: +7 (812) 461 01 01
-- Best regards,
Pavel Maslov, MS Controls Engineer at Pulsed power Lab Efremov Institute for Electro-Physical Apparatus
St. Petersburg, Russia
Mobile: +7 (951) 672 22 19
Landline: +7 (812) 461 01 01
- Replies:
- RE: [Scopes] BMP image record?? Mark Rivers
- References:
- [Scopes] BMP image record?? Pavel Masloff
- Re: [Scopes] BMP image record?? Dirk Zimoch
- Re: [Scopes] BMP image record?? Pavel Masloff
- Navigate by Date:
- Prev:
Re: labCa build fails on 64 bit Windows Till Straumann
- Next:
RE: [Scopes] BMP image record?? Mark Rivers
- 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: [Scopes] BMP image record?? Pavel Masloff
- Next:
RE: [Scopes] BMP image record?? Mark Rivers
- 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
|