Thanks for your responses!
Tim,
It does not process normally and I can’t get manual processing to work. When I disconnect the SEM, the CALC record does increment once, and prcesses. The record that causes the triggering, however, does not print
out that it processed with $(P):$(R):DEBUG:LISTEN.TPRO set to 1.
I changed my code to cut out the stream device support to see if I could get the link and the counter to work, and had success. See code below.
record(stringin,$(P):$(R):DEBUG:LISTEN) {
field(DESC,"Holds last SEM error")
field(TPRO,"1")
field(SCAN, ".1 second")
field(FLNK,"$(P):$(R):DEBUG:COUNTER")
field(INP, "dummy string")
}
record(calc,$(P):$(R):DEBUG:COUNTER) {
field(DESC,"Counter of # of errors")
field(SCAN,"Passive")
field(TPRO,"1")
field(CALC,"VAL+1")
}
![cid:image001.png@01D30179.2FDFE7F0](pngTzrZ0Qfg0d.png)
It seems like too many errors might be coming in from the SEM too fast for stream device to operate as expected. I’m getting around 150 errors per second right now. Also, it may be important to note that we are
actually interfacing with a hardware emulator that allows us to communicate with a virtual SEM. Unfortunately, something is wrong with the coding of the emulator so it dumps lots of errors through the debug port, complaining that the emulator cannot establish
full functionality due to a bad object reference. This should not have effect on the connection quality, but does dump a lot of errors onto us. It seems like the sheer message speed might be the problem since the LISTEN and COUNTER PVs don’t ever report that
they finish processing while the SEM is connected and sending errors quickly. It is strange to me though, that the LISTEN record is able to process to the point of getting the correct error messages, at least at a surface glance, since caget(…LISTEN) returns
an error with a sensible timestamp at any given time.
-Andrew
***
WARNING
***
EXTERNAL EMAIL -- This message originates from outside our organization.
Hi Andrew,
That calc record does increment on my system. Does it increment for you if you process it manually? Can you verify that the forward link actually is causing the calc record to process, by setting
$(P):$(R):DEBUG:COUNTER.TPRO to 1, and watching the IOC console?
Hello, and thanks for reading,
I’m having trouble keeping a counter for the number of errors coming in from an electron microscope (SEM). I’m using the Stream device driver to listen to incoming messages from the SEM, and when a message matches a certain format that
identifies it as an error message, the PV processes and stores the new error message, overwriting the last. When this happens I would like to have a second record process and increment a counter, so that I can keep track of the number of error messages coming
in.
My current setup gets the most recent error message correctly, but does not correctly increment the counter (the counter stays at zero). Here is the relevant code from the record definition file.
record(waveform,$(P):$(R):DEBUG:LISTEN) {
field(DESC,"Holds last SEM error")
field(DTYP,"stream")
field(NELM,"1000")
field(FTVL,"CHAR")
field(SCAN,"I/O Intr")
field(FLNK,"$(P):$(R):DEBUG:COUNTER")
field(INP, "@devhardware.proto debugListen() L5 0")
}
record(calc,$(P):$(R):DEBUG:COUNTER) {
field(DESC,"Counter of # of errors")
field(SCAN,"Passive")
field(INPA,"1")
field(CALC,"VAL+A")
}
When the first record processes due to an interrupt on a received error message, it is supposed to forward-link the calc record to process, causing an increment to the counter.
Any help or insight is appreciated.
-Andrew