Rewrite photon counter drivers

[GoogleCodeExporter]

The photon counter user-facing drivers need to be rewritten.  They cannot
be trusted to shut down under overload.

Instruments/Photon Counter/PC Take Data.vi:
It does these things in order, and checks for interrupt at each step:
0. Init PC
1. Wait for timeout of T Time
2. Serial poll
3. Read Ch A
4. Read Ch B
5. Check for overrun and close the spectrometer if needed.

Problems with this:
-PG drivers should not talk directly to SPEC drivers; higher level code
should do this
-PG driver should not check for overrun; higher level should
-Blocking task at any step could inhibit it from checking overrun and/or
closing spectrometer
-Wait until T time not needed; code should poll immediately
-Get rid of globals everywhere

Ideally, PG driver should just read both channels as quickly as possible
and let the higher-ups check overruns and/or close spectrometer.

In summary, give me the data points NOW, and stop dilly-dallying.

Original issue reported on code.google.com by sbr...@byu.net on 15 Apr 2009 at 3:10

[GoogleCodeExporter]

The "stop" button from the photon counter scanners uses a VI server reference 
-- this
is bad form.  I pulled it out and replaced it with a plain boolean.  But this 
raises
deeper questions.

Some behavior we need to characterize:
-Are local variables continuously updated, or just pushed on the stack?
-If LabView is executing a subVI, will the caller's variables get updated
continuously, and passed along to the callee?
-What is the labView analogue of a mutex?

One reason the "Vi server reference" may have been included is that it (might)
instantaneously propagate changes to the master "Stop" button.  This could be
important in cases where the photon counter is overloaded.  I think that 
connector
variables on the "execution stack" do not get updated until that subVI returns. 
 (Of
course, LabView flattens and unrolls lots of its code, so there might not even 
be an
execution stack at all!)

I spent r60 changing the server references to just plain booleans -- this may 
destroy
the purpose of the stop button.  It needs to stop instantly, even if it's 
waiting for
some call to return.

However, using a "server reference" seems to be like a PEEK or pointer -- and it
doesn't seem right.  I need to analyze how LabView does threads and mutexes and 
just
pass the stop button through a mutex.

Original comment by sbr...@byu.net on 23 Apr 2009 at 4:10

[GoogleCodeExporter]

I can't answer all of your questions, and I haven't looked closely at the code 
you're
talking about yet.  However, I do know that if you want to pass data between a 
subVI
and its caller (other than when you call the subVI and when it exits, 
respectively),
you have to use references.  (Or, I suppose, global variables, but those seem 
like
they'd be a worse idea.)  I don't know of another way.

For instance, if you call a subVI and want to get data from it in real time 
(say, to
plot on a graph), you would pass it a reference to the graph from the main VI, 
and
let it change the value of that graph using the reference.

In Lee's programs, he usually uses global variables to signal an 
application-wide
stop.  It sounds like he chose to use references here?  I'm about to join my 
family
for graduation festivities, so I don't have time to give this my attention at 
the
moment.  However, hopefully this explanation helps, and feel free to ask 
anything
else that I might be able to answer.

Original comment by mjjohn...@byu.net on 23 Apr 2009 at 4:52

[GoogleCodeExporter]

I don't know if this helps, but I suspect you (Steve) are correct about the 
need to
stop instantly. I remember Lee originally had the stop buttons wait until the 
next
data point before stopping, and I asked him to change that. If we were doing 20
seconds per point, or something like that, it would be really annoying to have 
to
wait that long before canceling. The server reference (which I'm not familiar 
with)
may have been his way to get around that problem.

Original comment by john.s.c...@gmail.com on 23 Apr 2009 at 5:24

[GoogleCodeExporter]

Probably need an all-out rewrite.  Leave alone for now.

Original comment by sbr...@byu.net on 23 Jul 2009 at 9:18

• Changed title: Rewrite photon counter drivers
• Added labels: Priority-Low
• Removed labels: Priority-High

[GoogleCodeExporter]

Original comment by sbr...@byu.net on 1 Oct 2009 at 12:37

[GoogleCodeExporter]

r371 makes progress on this.  I added things to the class, and cleaned up the
public-facing functions.

We still need to factor out all the different commands into individual, atomic,
mutex-protected functions.  What's the status with this?

Original comment by steve...@gmail.com on 12 Jan 2010 at 2:30

[GoogleCodeExporter]

Original comment by Dashingd...@gmail.com on 29 Jan 2010 at 9:28

[GoogleCodeExporter]

Mitch needs to remove everything that says "PC Comm" and replace it with Dallas'
atomic individual commands.

Original comment by sbr...@byu.net on 11 Feb 2010 at 7:36

• Added labels: Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

I replaced all "PC Comms" with their corresponding VISA-using program.

The PC control panel uses one program (just the code from "Serial Poll") that
contains a global variable. Do I need to get rid of that? It functions just 
great, as is.

Steve,

What did you mean by "I spent r60 changing the server references to just plain
booleans -- this may destroy
the purpose of the stop button.  It needs to stop instantly, even if it's 
waiting for
some call to return."

You say something may need to stop immediately. WHAT needs to stop immediately?

Original comment by AaronMit...@gmail.com on 16 Mar 2010 at 6:24

• Changed state: Fixed

[GoogleCodeExporter]

In an emergency, there needs to be a way to break out of any waiting loops in 
the PC
driver.

If the PMT overloads, the drivers shouldn't sit there counting for 2 seconds, or
whatever the T time is.  There should be a mechanism that aborts the take-data 
wait
loop in this situation.  This way the software can quickly close the slits and
protect the PMT.

The proper way to implement it is through a programming technique called a 
"signal"
or "event".  I don't know how to do this in LabVIEW, but I can go look it up.

Original comment by sbr...@byu.net on 16 Mar 2010 at 10:39