This may be overly complex, but I did something like this for graphs. It could be extended for charts I’m sure.
i created a reentrant graph vi using the jki state machine as the core.
- Pass in an Id number so the graphs can know which graph a command is intended for.
- pass in a user event ref representing a command message.
- pass in a queue reference representing a status message queue for each graph to send status back to the main vi.
- each graph uses a named queue to receive waveform data. The name is the graph vi clone name or a common name with the id number. Anything that lets the graphs poll for data and that the main can predict.
- After a graph is started using the call async method, the graph does its initialization then reports initialized to the main vi via the common status queue. The initialized status includes the id number and the graph vi clone name.
- that tells the main vi to start sending waveform data updates.
- the main vi also sends other commands to the graphs via the command event (each graphs event structure watches for these), My commands include things like adding new plots, forcing redraw, changing time references from absolute to relative, setting titles, setting axis labels, resizing, close, etc...
- A special id is used to tell all graphs to do something at the same time (-1).
I actually use this for multiple graph types... time vs value WFM, XY, bode. The whole idea being the common behavior, command, status, and data update approach. The graphs themselves handle other things, like mouse actions (annotations, legend movement, color changes, etc..).
hope that gives you some ideas? The JKI state machine is perfect for this kind of design on both sides (main vi and the graph vi).
XL600
