AlexA

Following on from what Shaun said, I use exactly the set up he described. I pull my images from an FPGA FIFO so I have it set up to give me a DVR which I pass through a series of queues (a messaging hierarchy). The ultimate endpoint of the DVR is the File IO process, but one of the intermediate message routers will periodically copy the data out from the DVR (at a rate of 30 Hz or similar) for display before piping the DVR onto the File IO process.

I couldn't find a clear answer to this while googling, so: Are Labview Events lossless like a queue, or are they lossy like notifiers? Further to that question, has anyone ever implemented a process responsible for File IO that gets its data via Events (I.e. subscribes to an event)? Especially, big data such as a continuous image stream? Finally, has anyone ever used Events with a DVR? The very idea of it kind of doesn't make sense to me as you're broadcasting a locking resource, but I thought I'd inquire anyway. Thanks in advance, Alex

Why not just use the same queue for all data? Have N different loops listening to N different channels. You can make your data type a waveform and set t0 on acquisition of data. You could even go one further and make it a cluster that encapsulates waveform + identifier. So you know at the other end whether you've got slow or fast data that's come in.

I'd do it by intercepting the pause request and storing your own time stamp. Subtract your time stamp from another time stamp you store on resume event. Or something like that.

Thanks for the opinions on MVC guys. To be honest, it's a little esoteric to me right now. Especially the concept that the model is just the data. I don't know how to fit that into my understanding where some process interacting with hardware is generating data. What part of that construct is the model? I'm thinking that what I think of as the process' state data is the model? (The data required to control the hardware, parameters etc.) The process is a "controller" and my decoupled UI which talks to the process via queues is the view?

Hi guys, Thanks for the opinions. @odoylerules The control references are not dynamically instantiated, or passed outside the GUI. It's just a way for the GUI messaging loop to manipulate control state if the process code updates it. One example is if a relative-position transducer signal is lost and then re-established, the apparent setpoint will change in the process (it automatically sets it to be the new position value, whatever it is), I propagate this change back to the UI so the user is aware what the setpoint now is.

Hi guys, I have a system which decouples UI and Process code in seperate VIs which communicate via queues. Some sort of MVC if that helps (I don't think in those terms). My questions are: When both UI and process code need to be aware of some state, e.g. "Move Slowly" option is flagged by the user. Either the process requests that state before obeying a command to move, or that state is copied into the process whenever the user modifies the flag. Which is better and why? Second, within the UI, I handle control changes with an event structure. This event structure then propagates the change to an internal control loop which handles performing calculations or alternatively updates graphs with data which it receives from the process. When I change the state of a control, I can either copy its state into a variable in the control loop, or I can maintain references to the controls and read it from the control loop as necessary. I have been doing the former, but I would like to do the latter as it would mean having one less copy of the data. Are there any gotchas I should be aware of? Finally, when a control only has a single purpose, i.e. its state will not be read in more than one control loop action, is it best practise to read the control directly in the control loop, rather than seperate it into the event structure and either use a reference to read it, or copy its state. Thanks in advance, Alex

Hello all, I had a play and managed to figure out how to launch LVMerge based on the previous scripts in this thread. This is the bash script I use: #!/bin/bash# Method to determine absolute path# The -W parameter on the pwd command is necessary to return the Windows version of the path.# Not using the -W parameter will result in a conversion of temp directory to a 'tmp' path meaningful only in the Linux # environment.# Piping the result through tr '/' '' translates the forward slashes to backslashes.# Windows understands forward slashes, but LVMerge.exe does not.abspath () { ( DIR=$(dirname "$1") FN=$(basename "$1") cd "$DIR" printf "%s/%s" "$(pwd -W)" "$FN" | tr '/' '' )}lvmerge="C:Program FilesNational InstrumentsSharedLabVIEW MergeLVMerge.exe"remote=$(abspath "$1")local=$(abspath "$2")merged=$(abspath "$3")base=$(abspath "$4")echo Launching "$lvmerge"exec "$lvmerge" "$base" "$remote" "$local" "$merged" The relevant section of my global .gitconfig file is configure as follows: [merge "lvmerge"] command = lvmergewrapper.sh "$LOCAL" "$REMOTE" "$MERGED" "$BASE"[mergetool "sourcetree"] cmd = 'C:/GitRepositories/lvmergewrapper.sh' $REMOTE $LOCAL $MERGED $BASE trustExitCode = true And finally, in sourcetree the options menu under the diff tab is set to Custom with Diff Command: C:/GitRepositories/lvmergewrapper.sh and Arguments: "$REMOTE" "$LOCAL" "$MERGED" "$BASE" I'm not sure exactly what trustExitCode = true does, but I did notice that choosing "No" in the accept merge dialog of the LVMerge tool results in the .git lock file not being cleared and consequently I couldn't do any git operations without first deleting that file. It may be the case that trustExitCode should be set to false. If anyone feels inclined to map this behaviour out, I'd love to hear back. I'm sure I'll probably stumble across the right way to do it eventually but hey. Cheers, Alex Edit: I'm not sure if some parts of the .gitconfig file are redundant in that they are only relevant to calling it from the commandline? Really not sure, but it seems to work this way (Hopefully it doesn't twist up which ones are remote and which ones are local).

Thanks Hooovah

A couple of follow up questions on the nature of TDMS files. 1) Do TDMS Files need to have their pointer maintained? As in, update the reference to the file after a write? (In a similar fashion to reading/writing files with low level vis). 2) If they don't need to have the pointer maintained (opened in append mode or something), how expensive is an open operation assuming the file already exists? In other words, can I get away with calling open every time I have data to stream? 3) Finally, if the answer to question 2 is yes you can get away with it, does the same hold true for the special Asynchronous versions which must be configured on open?

Ahh, there's a slight misunderstanding, the File IO is not displaying the images, that's happening in a separate UI actor.

Hmmm, interesting. So do your low level processes trigger events which your UI is registered for? I'm trying to think how the one loop arrangement differs in anything other than an aesthetic sense?Also, if you need to save data, how does that work? Is the File IO actor event structure based as well?

Doesn't OOP really boil down to trying to encapsulate related functionality into effectively atomic objects, from the point of view of external components? In other words, code only expresses well defined interfaces to the external world? Everything else about how exactly that's implemented seems to me to be cruft.

Thanks for the info Jack, I'll check out the repo.

Hi All, I've been hunting for an explicit answer to this question but can't find anything. The question in a nut shell is: Is it good practise to place potentially "big" (footprint wise) indicators such as graphs and charts in an event structure and update them via dynamic event? Here's the context for my question: Shown below is the block diagram of a UI component responsible for offering the interface to a particular hardware component. The Event structure handles controls, the message handling loop performs value updates (updates the image display). I just assumed this was the right way round to do things but now I'm second guessing that assumption. The following is the BD for the associated process (forgive the poor formatting, I'm still hacking things around consistently). This design was originally motivated by having the process running on an RT machine and the UI on a windows machine. I've since moved everything to a Windows machine and am now wondering whether I'm doing needless message passing. Does it make sense to cut out the messaging loops from both VI's, and mash the event loop which handles UI together with the task loop that monitors the FPGA? In this case, instead of sending a message with the DVR from the Task loop, it would trigger a Dynamic event (at a lower frequency, limited to 30 Hz display updates). The Dynamic event would update the image control. Apart from my "known unknown" in terms of the event structure's ability to handle "big" data, are there any other gotchas with handling the UI purely in the event loop? One I can think of is that now important hardware state (such as an FPGA reference) has to be explicitly maintained in the event loop, this makes keeping track of everything easier but means that the hardware is tightly coupled to the UI. Hope you guys can point the way, Cheers, Alex

Yeah, I'm not really advocating it. It's just the readiest thing I had on hand to do some crude profiling.

I have a question kind of related to this. I have a couple of processes (subVI's) which consist of a message handling loop and a task loop in parallel. The task loop sometimes requires parameter updates, which thus far have been passed using local variables (there are no time critical actions associated with these parameters). These sub VI's never have their front panel opened. What I wanted to know is, do local variables still go to the UI thread even if the front panel isn't open? Secondary to that, how do 0 timeout queues compare to local variables for passing small amounts of data (a cluster of 3-4 parameters say)?

Yeah, I benchmarked the global approach. I had one writer and two readers. I tried it via deletion of DVR, and with the normal read FIFO method associated with FPGAs. In both cases, the performance (judging by CPU utilisation) averaged about 10 % worse. It would appear from my very crude tests that DVR is faster.

Hi Shaun, I'm kind of confused by the architecture you're suggesting. Say the data I'm working with is an array of U8 values (pixels). Would you suggest making the global an array of the same size? Or a larger array and wrap it in a FGV?

Each image is 1MB, running at a rate of 100 FPS kind of chokes things. The frame grabber is really a PXI FPGA connected to the PC over a 250MB/s MXI->PCIe x1 connection. I'm now starting to get curious about how messaging works, does it wrap the data in some form of pointer? Or is there an explicit copy when you load a message with data? @ShaunR I've benchmarked the tdms writes before. I'm using an SSD, so they average about 4ms with periodic spikes to 10-12ms. As per thread title, the images are actually written as a U8 array straight into tdms.

Ok, I had to go back and check this because it didn't sound right. It turns out, even messaging the data around results in this buffer phenomenon. I guess I never saw it because I wasn't trying to push the code this hard. Hmmmm. In that case, it would seem that messaging the DVR to an FIO process does give some advantages.

Ok, I've spent a couple of hours on this so far and haven't had all that much success. I configured it in two ways. Firstly, I would message the DVR reference to my central handler which was keeping track of a timer value. If the value was greater than 40 ms (frame rate of 25 Hz), then the DVR was pulled from the message and the data copied out from the DVR and sent to the UI for display. The DVR is then deleted (If the timer wasn't greater than 40 ms, the DVR was deleted). Alternatively, the user can select to stream to disk, in which case, the same copy to UI is made, but instead of deleting the DVR, it is sent on to a File IO engine which uses the Asynch TDMS VIs to write to disk. With this configuration, I noticed a significant drop in CPU use compared to just messaging the data around, something on the order of 15 to 20%, but the whole processing chain was not able to keep up with images at a rate of 100 FPS, the buffer would slowly fill up then images would become disjointed as the data started to time out. I did not observe this phenomenon when messaging the actual data around (with similar UI update restrictions). The second configuration I tried was opening the asynch .tdms file in the same VI which is performing the FIFO read. This time the asynch write was performed in the same loop as the FIFO read, and the data for the user was copied out with similar timing restrictions as above, but the timer was done in the form of the timed loop which reads the FIFO. The second configuration had even worse performance, no CPU utilisation improvements and the buffer filled up even faster. I definitely haven't explored all the facts at play here, and I'm most likely doing something stupid, but with my naive investigation so far, it would seem that the DVR release notification mechanism is kind of slow... I tested the case where the code did nothing except obtain the DVR ref and then delete again straight away, no UI updates or anything, and the buffer still slowly filled up at 100 FPS. Anyone got any insight? Cheers, Alex

Thanks Paul, that got it working.

Hey, I'm trying to get this set up. Have copied your code across with the appropriate modifications to the paths. How do you actually configure sourcetree so that it calls the external diff tool? i.e. do you leave it calling the system diff, or write a command into the custom call part?

Thanks for the info guys, I'll put a couple of hours into it this weekend and see what I can figure out about the DVR from FPGA. Will report back here. Cheers