Multi Core synchronisation on traffic lights

[flak714]

Hi altenbach,

Sorry for the late reply.

I've kept the timed loop so everything is forced onto 1 CPU, just to keep my lecturer happy.

The emergency stop is still something I'm finding hard to crack. Basically if one of the pairs is on amber and the emergency stop is pressed then it will go to green for 2 seconds and then cycle back to red the normal way and stay on red even if the user suddenly turns emergency stop off a second later. The reason is to keep it safe so there are no sudden changes in light patterns which could confuse drivers.

Thanks for your help, I've attached what I've got so far but feeling I'm going in the wrong direction again 😕

[altenbach]

Get rid of the while loop. Only one loop is necessary. Put the shift register in the timed loop instead. Your case structure contains a huge amount of code that is duplicated into nearly all cases. Shared code should be outside the case structure.

You don't need an event structure, because you are looping anyway. Simply read the button states to decide what to do next. Later you want to remotely control these e.g. via shared variables, so you need to poll anyway.

Here's a very quick simplification attempt using a radiobutton for the lights and an enum for the states. Maybe it can give you some ideas. (it is in no way complete...)

[flak714]

Hi everyone 🙂

I haven't been on here for a while as I've been trying to get most of it done on my own but thanks for all the help so far.

I'm now on the communication stage and have come to a "fork in the road" and was looking for some advice.

I've attached the current VIs in my project (please ignore some of the messy wiring :s). As this would ideally be for a multi computer system I didn't go for using queues or notifiers for syncronisation and instead started off by trying to make my own messaging system, these are on the top timed loops within the VIs. I have also made a copied system using semaphores instead (the bottom timed loop).

Would it be better for me to continue working on the semaphores or my own system?

Thanks for looking and hope you have a good break before the new year 🙂

Matt

[johnsold]

Matt,

The detailed help for the semaphore VIs clearly states that semaphores cannot communicate between LV application instances.  So you cannot use them as the basis for communicating between computers.  The shared variable appears to be the communications process in both cases anyway.  You should probably move the Obtain Semaphore Reference outside the loop so that you do not get a new reference each time the loop iterates.  And you should probably close the reference after the loop finishes.

Shared variables are not available on my platform so I have no experience with them.

It appears that you both read and write the shared variable from both VIs. Because they use networked communications, it is possible that delays may occur (multi-computer system). What are the consequences of a delayed message? What about race conditions? 

Perhaps each message should include a source ID and a timestamp.  This would enable any VI which reads the message to determine who sent it and when.

Lynn

[flak714]

Hi Lynn,

Thanks, I must have missed that in the detailed help. I'll stick to my own message protocol.

The reason for using the same variable for reading and writing is to simulate the cable that would run from the traffic lights to the engineers console (which could be IP based hence the shared variable over serial)

I'm finding it hard to understand how I can prevent a race condition where both VIs try to write at exactly the same time as they could both read the variable as free at the same time. The shared variable uses a FIFO buffer, would this stop the race condition from happening?

I understand you cannot view the shared variable but I have attached my VI's incase you wanted to view the structure of my "protocol"

Thanks so much for the help!