accessing data between VI's using global variable

[mikeporter]

Actually, no.

I could modify the code to use any of the options that I mentioned in an earlier post, but I can't tell you what the correct one is because that determination can only be made in the broader context of your application as a whole - whihc includes things like where it is going to be used, how it's going to be used, who is going to maintain the code -- and a bunch more stuff.

The thing with enginnering is that it deals with existing needs -- holes in reality, so to speak. Now as engineers we don't have a say in how big the holes are or what shape they have. Our job is to make something that fills them as exactly as possible.

Mike...

[swap15]

HI mike,

Let me explain you the situation. I have two VI's,  In one VI I am reading the CAN data from the Steering angle sensor and writing it in a text file contineously. In my other VI, I am reading the CAN data from different sensor (i.e. Temperature sensor). Now, I want to write this tempearature CAN data into the text file in which I am writing CAN data from steering angle sensor . These are two different VI's. If I use global variables to transfer data between these VI's, there might be a problem of race condition (as this is a contineous process and for many days).

Now could you please tell me if you have any idea to do it? If you have need further info please ask.

regards,

swap

[crossrulz]

I would use a third loop for the logging of the data.  I would then use Queues to send the data to the logging loop.  That way you don't lose any data and the logging won't slow everybody else down since it is done in parallel.

[mikeporter]

A separate datalogging loop is just what I was going to suggest, but my preference for passing the data would be a user defined event.

We already know what his temperature monitor loop looks like, and although the code that is there needs some rework, it's not that bad so I'm assuming that the steering position one will be very similar. Now adding the datalogger means that there are 3 VIs that, in addition to needing to communicate, all need to be stopped together. Event structures are very good for providing a way to create a universal application shutdown command. Unfortunately, events don't play well with queues -- and events have queues behind them anyway.

Plus there is something still missing. Where is the operator interface? The operator is not going to get anything meaningful from staring at clusters. They are probably going to want to see graphs and things. So now we have a 4th loop -- and another reason for using an event to pass data: multiple locations in a program can receive the same event. So you have the datalogger catching the event so it can be saved, the GUI catching the event so the data can be graphed, analyzed or whatever.

Notice that this structure is also scalable in that it is easy to add additional data sources, and maintainable in that each component is free to change the specifics of what it does without impacting the rest of the application.

If this sounds interesting, we can talk about the details.

Mike...