I'm using LabVIEW and its VISA capabilities to control a Keithley 2635A source meter. Whenever I try to identify the device, it works just fine, both in reading and writing.
viWRITE(*IDN?) /* VISA subVI to send the command to the machine */
viREAD /* VISA subVI to read output */
However, as soon as I set the voltage (or current), it does so. Then I send the command to perform a measurement, but I'm not able to read that data, with the error
VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.
After that, I can not read the *IDN? output either anymore.
The source meter is connected to the PC via a National Instrument GPIB-USB-HS adaptor.
EDIT: I forgot to add, this happens in the VISA Interactive Control program as well.
Ok, apparently the documentation is not very clear. What the smua.measure.X() (where X is the needed parameter) command does is, of course, writing the measurement outcome on a buffer. In order to read that buffer, however, the simple viREAD[] is not sufficient.
So basically the answer was to simply add a print command: this way I have
viWRITE[print(smua.measure.X())];
viREAD[]
And I don't have the error anymore. Not sure why such a command is needed, but that's that. Thank you all for your time answering me.
As #Tom Blodget mentions in the comments, the machine may not have any response to read after you set the voltage. The *IDN? string is both command and query. That is, you will write the command *IDN? and read the result. Some commands do not have any response to read. Here's a quick test to see if you should be reading from the instrument. The following code is in python; I made up the GPIB command to set voltage.
sm = SourceMonitor()
# Prints out IDN
sm.query('*IDN?')
# Prints out current voltage (change this to your actual command)
sm.query('SOUR:VOLT?')
# Set a new voltage
sm.write('SOUR:VOLT 1V')
# Read the new voltage
sm.query('SOUR:VOLT?')
Note that question-marked GPIB commands and the query are used when you expect to get a response from the instrument. The instrument won't give a response for the write command. Query is a combination of write(...) and read(...). If you're using LabView, you may have to write the write and read separately.
If you need verification that the machine received your instruction and acted on it, most instruments have the following common commands:
*OPC? query to see if the operation is complete
SYST:ERR? query to see if any error was generated
Add a question mark ? to the end of the GPIB command used to set the voltage
Related
we bought a Printronix RFID printer T4304 with these dates:
FirmwareP301189 V1.21A
Serial NumberT4K431948007
Our wish is
to produce RFID-Labels with an QR-Code which includes the EPC-number
of the label. The QR-Code shall look like this:
http://qr.mycompany.com/epc/E280689123456789012345
We were hoping to use it with the Software Nicelabel. But Nicelabel
is only able to produce a QR-Code with only the EPC-Number but not
with our http://qr.my..../epc/ in front.
I had the idea to save the printjob as file. So I was able to
manipulate the file and send that file as printjob to the Printronix
printer like this:
lpr -S 192.168.1.2 -P raw myprintjob.prn
I found the document PTX_PRM_PGL_P7_253642C.pdf
which describes how the printer language is working. But I cannot
fulfill my destination.
My myprintjob.prn looks like this:
!PTX_SETUP
ENGINE-IMAGE_SHFT_H;0
ENGINE-IMAGE_SHFT_V;0
ENGINE-WIDTH;04146.
PTX_END
~NORMAL
~PIOFF
~DELETE LOGO;*ALL
~PAPER;INTENSITY 8;MEDIA 1;FEED SHIFT 0;CUT 0;PAUSE 0;TYPE 0;LABELS 2;SPEED IPS 6;SLEW IPS 6
~CREATE;FRM;99
SCALE;DOT;300;300
RFRTAG;96;EPC
96;DF511;H
STOP
ISET;0
FONT;FACE 92250
ALPHA
AF511;24;INV;POINT;329;1033;10;10;
STOP
BARCODE
QRCODE;INV;XD9;T2;E0;I1;95;843;
"http://qr.mycompany.com/epc/","EPCCODE"
STOP
END
~EXECUTE;FRM
~REPEAT;1
~AF511;<DF511>
~NORMAL
The result is a QRcode which only includes the first part of the string:
"http://qr.mycompany.com/epc/"
but not the "EPCCODE". I am looking for a hint how to do this.
Maybe I could find out the EPC-code via REST or telnet or so and create a special printjob for every single label?
Thanks for your help,
Richard
Printronix T4000, talk with port 9100 to get info from the printer
Author
Richard Lippmann, Stadt Zirndorf, EDV
Documentinformation
name: talk-with-port9100-to-get-infos-from-printronix-rfid-printer.md
revision: 2021-12-02 - init
What I want to achieve
I want to know the RFID-code from the label which is under the print-head.
With this information I am able to build a printjob with Qrcode which includes
the RFID-EPC.
I was not able to find out how to create a print-job with a qr-code.
I do not want this information in qrcode: ABC1234...567
But I want this information in qrcode: http://qr.mydomain.com/rfid/epc/ABC1234...567
With that I am able to take a picture of the label and go to a web-application
which helps me further with the device the label is on.
Documenation, where to find information
The printer language is described in the document which is easy to google: PTX_PRM_PGL_P7_253642C.pdf
My environment
Printronix T4000 printer with RFID-unit to read the RFID from the current label.
How to get info back from my printer
Usually Port 9100 is used to send a printjob to the Printronix-printer. Send job,
don't receive data. But you can switch the printer to be verbose, to send you
back information over the 9100-connection.
Glossary
EPC = this is the unique number which is in every RFID-label, just like
a MAC-address in a network card
PGL = the printer language. We can send printjobs with it, but also get information
from the printer about Configuration etc.
Human connect to the printer via Linux commandline
ssh me#shell.mydomain.com
export MYPRINTER=192.168.100.3
nc -v $MYPRINTER 9100
Put verbose mode on
The printer usually only receives information, but does not talk back.
You have to switch on the back-communication.
~CONFIG
SNOOP;STATUS
END
Put verbose mode off
I you are programming this interface with a programming
language like python, perl, ... it's a good idea to switch
verbose mode off after you did your job.
~CONFIG
SNOOP;OFF
END
IDENTITY
To see information:
put verbose mode on
send ~IDENTITY command
put verbose mode off
~CONFIG
SNOOP;STATUS
END
~IDENTITY
The result is:
T43040,V1.21A,12,131072KB
STATUS
To see information:
put verbose mode on
send ~IDENTITY command
put verbose mode off
~CONFIG
SNOOP;STATUS
END
~STATUS
The result is:
BUSY;0
PAPER;0
RIBBON;0
PRINT HEAD;0
COUNT;000
GAP;0
HEAD HOT;0
CUT COUNT;000000000
PRINT DIST;000001529
PRCT COMPLETE;000
TOF SYNCED;1
SENSED DIST;00450
END
Read one RFID-EPC-code from current label
These are things mentioned in this command:
~CREATE - start creating a new "form" (or subroutine to execute later)
VERIFY - the name of the subroutine we are creating. Keep it simple,
less than 15 characters, no special signs (see docu PTX_PRM_PGL_P7_253642C
page 60 under "CREATE" and page 29 under "Form Name" for exact informations)
NOMOTION - don't move the label to the next one after executing this job
DF511 = This is a variable-name, there seem to be a lot of variables in the printer
which are called by their numbers: DF1, DF2, ... I don't know which one I am
allowed to use, DF511 seems to work
96 = the RFID-EPC on my labels are 96 Bits long
H = Hexnumbers, the code is 96 Bit long, but I would like to see it like this:
ABC1234...567
VERIFY - a command to send information to the commandline.
~EXECUTE;VERIFY;1 - execute the form 1 time
~CONFIG
SNOOP;STATUS
END
~CREATE;VERIFY;432;NOMOTION
RFRTAG;96;EPC
96;DF511;H
STOP
VERIFY;DF511;H;*STARTEPC=*;*=ENDEPC\n*
END
~EXECUTE;VERIFY;1
~NORMAL
The result is:
STARTEPC=E28068940000501EC931EC87=ENDEPC
Read two RFID-EPC-codes
Reads 2 Barcodes and gives back the EPC-codes. With this command the label get
sent (moved) through the printer.
These are things mentioned in this command:
~CREATE - start creating a new "form" (or subroutine to execute later)
VERIFY - the name of the subroutine we are creating. Keep it simple,
less than 15 characters, no special signs (see docu PTX_PRM_PGL_P7_253642C
page 60 under "CREATE" and page 29 under "Form Name" for exact informations)
NOMOTION - don't move the label to the next one after executing this job
DF511 = This is a variable-name, there seem to be a lot of variables in the printer
which are called by their numbers: DF1, DF2, ... I don't know which one I am
allowed to use, DF511 seems to work
96 = the RFID-EPC on my labels are 96 Bits long
H = Hexnumbers, the code is 96 Bit long, but I would like to see it like this:
ABC1234...567
VERIFY - a command to send information to the commandline.
~EXECUTE;VERIFY;1 - execute the form 1 time
~CONFIG
SNOOP;STATUS
END
~CREATE;VERIFY;432
RFRTAG;96;EPC
96;DF511;H
STOP
VERIFY;DF511;H;*STARTEPC=*;*=ENDEPC\n*
END
~EXECUTE;VERIFY;2
~NORMAL
The result is:
STARTEPC=E28068940000501EC931EC87=ENDEPC
STARTEPC=E28068940000401EC931EC86=ENDEPC
While this Q/A does not address the actual issue of: How to detect with client (eg redis-py) that redis is running out of memory constraint not by machine but by the maxmem configuration? Before inserts fail which command to use in the programm to detect about to be full?
My first guess is: info and check if used_memory_peak < maxmem setting. Is this correct?
(Besides, for out of machine memory, since defrag, use which setting, none of the returned INFO fields help here)
Well should i just try an insert and see if fail (but that would be after the fact then.)
Trail and error, good enough tested by running
while true; do redis-cli lpush mm longstringhere; done; results on maxmem - used_memory < 0.1MB with insert failures:
(error) OOM command not allowed when used memory > 'maxmemory'.
So i have set i poll it via redis-py client and once the diff goes <1mb threshold throw up, sry raise Error of course. Make sure the user_memory memory addon of your longest command is < threshold too of course otherwise you run into it on insert.
I try to figure how to calc the ~percentage of used mem so i get notification way earlier eg 90% of maxmem, therefore this solution is fine.
Info dump:
# Memory
used_memory:3126272
used_memory_human:2.98M
used_memory_rss:5292032
used_memory_rss_human:5.05M
used_memory_peak:4914296
used_memory_peak_human:4.69M
used_memory_peak_perc:63.62%
used_memory_overhead:696654...
Furthermore maxmem is not a hardcap, when running it further by eg adding members to existing set.
used_memory:3162584
used_memory_human:3.02M
code to get percent 0-100
rmem_info = pipe.info(section='memory')
{'redis_mem_percent': math.ceil(rmem_info['used_memory'] / rmem_info['maxmemory'] *100)}
I installed ROS melodic version in Ubuntu 18.04.
I'm running a rosbag in the background to mock cameras in messages rostopics.
I set the camera names in rosparams and iterated through it to capture each camera topics.
I'm using message_filter ApproximateTimeSynchronizer to get time synchronized data as mentioned in the official documentation,
http://wiki.ros.org/message_filters
But most of the time the callback function to ApproximateTimeSynchronizer is not being called/is having delay. The code snippet I'm using is given below:
What am I doing wrong here?
def camera_callback(*args):
pass # Other logic comes here
rospy.init_node('my_listener', anonymous=True)
camera_object_data = []
for camera_name in rospy.get_param('/my/cameras'):
camera_object_data.append(message_filters.Subscriber(
'/{}/hd/camera_info'.format(camera_name), CameraInfo))
camera_object_data.append(message_filters.Subscriber(
'/{}/hd/image_color_rect'.format(camera_name), Image))
camera_object_data.append(message_filters.Subscriber(
'/{}/qhd/image_depth_rect'.format(camera_name), Image))
camera_object_data.append(message_filters.Subscriber(
'/{}/qhd/points'.format(camera_name), PointCloud2)
topic_list = [filter_obj for filter_obj in camera_object_data]
ts = message_filters.ApproximateTimeSynchronizer(topic_list, 10, 1, allow_headerless=True)
ts.registerCallback(camera_callback)
rospy.spin()
Looking at your code, it seems correct. There is, however, a trouble with perhaps bad timestamps and ergo this synchronizer as well, see http://wiki.ros.org/message_filters/ApproximateTime for algorithm assumptions.
My recommendation is to write a corresponding node that publishes empty versions of these four msgs all at the same time. If it's still not working in this perfect scenario, there is an issue with the code above. If it is working just fine, then you need to pay attention to the headers.
Given that you have it as a bag file, you can step through the msgs on the command line and observe the timestamps as well. (Can also step within python).
$ rosbag play --pause recorded1.bag # step through msgs by pressing 's'
On time-noisy msgs with small payloads, I've just written a node to listen to all these msgs, and republish them all with the latest time found on any of them (for sync'd logging to csv). Not optimal, but it should reveal where the issue lies.
I am writing a small program in Progress that needs to write an error message to the system's standard error. What ways, simple if at all possible, can I use to print to standard error?
I am using OpenEdge 11.3.
When on Windows (10.2B+) you can use .NET:
System.Console:Error:WriteLine ("This is an error message") .
together with
prowin32 2> stderr.out
Progress doesn't provide a way to write to stderr - the easiest way I can think of is to output-through an external program that takes stdin and echoes it to stderr.
You could look into LOG-MANAGER:WRITE-MESSAGE. It won't log to standard output or standard error, but to a client-specific log. This log should be monitored in any case (specifically if the client is an application server).
From the documentation:
For an interactive or batch client, the WRITE-MESSAGE( ) method writes the log entries to the log file specified by the LOGFILE-NAME attribute or the Client Logging (-clientlog) startup parameter. For WebSpeed agents and AppServer servers, the WRITE-MESSAGE() method writes the log entries to the server log file. For DataServers, the WRITE-MESSAGE() method writes the log entries to the log file specified by the DataServer Logging (-dslog) startup parameter.
LOG-MANAGER:WRITE-MESSAGE("Got here, x=" + STRING(x), "DEBUG1").
Will write this in the log:
[04/12/05#13:19:19.742-0500] P-003616 T-001984 1 4GL DEBUG1 Got here, x=5
There are quite a lot of options regarding the LOG-MANAGER system, what messages to display, where the file is placed, etc.
There is no easy way, but in Unixen you can always do something like this using OUTPUT THROUGH (untested):
output through "cat >&2" no-echo unbuffered.
Alternatively -- and this is tested -- if you just want error messages from a batch-mode program to go to standard out then
output through "tee" ...
...definitely works.
Hi I am using LabView 2012, Delphi XE7 and GPIB (I think 488.2), Win7 SP1 and Agilent 53131A.
I used the given NI examples.
NI Labview example - Found in LabVIEW's help - GPIB.vi.
I tried writing and reading to query frequencies from 2 channels and they are successful.
They are are sent and read in succession.
*IDN?
:FUNC 'FREQ 1'
:READ:FREQ?
If they are successful, that meant GPIB for Agilent and NI MAX and driver are successfully installed and configured.
I am also able to use KeySight Connection Expert's to write and read, Again it is also successful.
However, When I used the given NI example in Delphi. Orginally it was saved as Delphi 3 or 4.
I used the Scope Simple example for universal counter. I used it mostly for writing and reading in the simple way. All it needs initialization, read/write and cleanup
I changed the following codes as shown below, in SimpleForm.pas
The detected device is at GPIB0::3::INSTR so, at line 32,
PRIMARY_ADDR_OF_COUNTER = 3;
String to write and read so, at line 132,
CommandBox.Text := '*IDN?';
then it was compiled with no error and run.
String to write was successfully
But upon reading, it was not successfully.
The string output is supposed to be ' HEWLETT-PACKARD,53131A,0,4806'.
The error at the end of the program is as follows below:-
Unable to read from device
ibsta = SC000 <ERR TMO>
iberr = 6 <EABO>
ibcntl = 0
From these readings, I figured out as :-
EABO means abort
I am not familiar with working of GPIB. Kindly advise.
You are correct that EABO is the identifier for an abort. In addition, we can see from ibsta = SC000 <ERR TMO> that the cause of the abort was a GPIB timeout error. I am not familiar with Keysight Connection Expert or your instrument, but since the error was from GPIB timeout, the most likely causes are:
The query was improperly formatted and the instrument thought it was just a write statement with no response needed. (That's probably why the write function had no error, but the read function timed out.)
The query was improperly formatted and the instrument returned an error.
Instrument needs to have 'Talker' capability enabled to send data. (Most instruments do this automatically with queries.)
For more information on generic GPIB commands, see this reference from the folks at National Instruments.