Introduction: these figures illustrate the suggested changes to the baseline pcon/pdet LabVIEW modules delivered by SAAO to UW. Figures 1-5 illustrate the suggested change in architecture, step by step. Figures 6-8 illustrate how SAAO and UW would be able to continue development of their respective software modules.
I have coded up everything shown in Figure 5. At the end of this document, I offer some step-by-step activities to explore the items shown in Figure 5. The software is here. After you unzip it, do the suggested activities.
Figure 1: The baseline architecture. This is what we started with, and discussed in recent emails.
Figure 2: Break the GUI code out of the rest of pdet.vi. Use a single GUI in two places. We both use pcon.vi, share upgrades, etc. pdet.vi is descoped, losing the GUI part. But there is a DSS-monitoring loop in there that forms the core of this descoped version. Note to Luis: your C-code bindings don't change. You monitor the DSS for the precedure and command, just as you do now, and feed your Call Library Function nodes just as you do now.
Note that I don't seriously suggest PDET using the DSS on PCON. This figure is just a stepping stone to the next one.
Figure 3: Magical platform-independent DSS. I have this all coded and tested. The idea is that on the pdet.vi panel, there's a button called "Remote?" If true, the DSS is sought out. If false, then a secret global variable is used to mimic the cache of the DSS. Note that if both PCON and PDET are being used, then the PDET operator can wrest control away from PCON by un-clicking the "Remote?" button on pdet.vi.
Figure 4: Isolate the C-code runner. pdet.vi gets descoped again, and now is just the C-Code runner. It monitors pdet-global.vi for commands and writes status data into pdet-global.vi.
Figure 5: Simulate the C-Code Runner with a LabVIEW module that monitors the pdet-global, and provides fake status based on the procedure and command inputs. I coded one of these, it works quite nicely. This simulator illustrates how we monitor the procedure and update the status in pdet-global.
Figure 6: How does Luis build and debug the C-Code Runner? The pdet-global has an instance of the procedure cluster dropped onto it, and an instance of the status cluster dropped on it. (The very same clusters used by other VIs e.g. pcon.vi.) Recall that the LabVIEW user can open the global's front panel, and by using the little "hand" cursor, manipulate the global's data objects directly. The pdet-global's front panel is itself a GUI, using the very same procedure cluster that pcon.vi uses! But without Windows, networks, other CPUs, socket servers, or any other distraction! It's a GUI without even a wiring diagram!
C-Code Runner (pdet.vi) is now reduced to its bare-bones operation of the detector hardware. It monitors a global variable for the procedure, and updates the global with status info sent back by the C-code. The code-base that SAAO supports is far smaller than before. If we're smart, we will "genericize" the pdet-global to include SALTICAM and HRS needs, thereby re-using all the GUI/DSS infrastructure, requiring SAAO only to provide "C-code runners" for each device.
Figure 7: Here's how I debugged pdss.vi. I fired up my simulator and opened the front panel of the secret global variable used in DSS-local mode. Note that this secret global is not pdet-global, it is used internally by the platform-independent DSS module I build. By direct manipulation of the secret global's front panel, I can pass data through pdss.vi into the simulator and back.
Figure 8: Shows how PFIS/PCON development can proceed. Using the simulator and the platform-independent DSS, I can write PFIS code in my control system that interacts with the simulator (e.g. the shuffle modes). The handshaking through the DSS is all in place, I can make sure my end of the interaction works. When we join up PCON and PDET, we have a good chance of everything working.
I can run the whole system on any LabVIEW box, right down to watching the exposure time remaining count down to zero! So I can code my shuffle-and-nod modes, for example, on my Mac, using the simulator, and we will be assured that they will work correctly with the real system. Because the interface to the simulator and the C-code runner is through the same pdet-global, then that acts as strict interface control "document" if you will. The pdet-global is the eye of the needle through which any customer must pass.
Concern: Have I made things more complicated? I thought hard about this. We started with a conceptually simple 2 module system, pcon/pdet. But looking at Figure 4, we end up only adding a 3rd, the dss.vi intermediary. The DSS stuff is embedded in the sub-VIs used by pcon.vi and pdss.vi. They are not separately-started-up modules.
In full-dress mode, you'd fire up pcon.vi, pdss.vi, and pdet.vi all on the Linux box, running in non-Remote? mode. But that's more than you need for local work. pcon.vi just has an instance of the procedure and status clusters on it; but as I pointed out, so does pdet-global! pdet-global really boils down to a non-networked GUI.
After you get my new LabVIEW modules, unzip the file (discard any previous versions, some files have changed names) and follow these suggested activities to learn about the suggested changes to the pcon/pdet architecture.
Lowest level DSS tools (in the ccd-dss folder)
Handshake VIs (in the ccd-vis folder)
Figure 6 (GUI with no wiring diagram!)
Figure 8 (end-to-end, no hardware present)