Running Two Scripts at the Same Time

I am programming an open source board with the Arduino toolbox on Matlab. I have one script for a buzzer and another one for a light and I want to run them simultaneously so I can get the light and buzzer to respond at the same time. Is there a way I can do this using the Parallel Computing Toolbox?

Both scripts are for loops that do not have any inputs or outputs

[minmi]

If I placed everything in one loop, the buzzer would go off before or after the light but I need both to occur at the same time

Answer 1

[Walter Roberson]

If both the buzzer and the light are being controlled by the same Arduino, then NO. Only one parallel worker can communicate with any one hardware device, which in this case would be the serial port that is used to talk to the Arduino.

[Guillaume]

... and that is a good thing because if both the buzzer and light code attempt to talk to the board at the same time, it's going to get messy.

It's not really clear what the buzzer and light code do, but most likely a timer based or event based architecture would be better than a multithreaded architecture. Neither timer or event require a special toolbox.

[Walter Roberson]

"the buzzer would go off before or after the light but I need both to occur at the same time"

You will need to use a quite different connection to the buzzer and the light. You will need to arrange to have them run independently but be triggered to turn on or off, and you will need to wire the triggers for the two together so that the triggers are received at the same time. See for example the discussion of genlock

But as long as you have them controlled by the same arduino, or even different arduino connected to the same host PC, then it will not be possible to get them to occur at the same time.

For example if you were using an Arduino Due, since the best you could possibly do to change the state of two different devices would be to change the state in two consecutive hardware instructions, you would not possibly be able to synchronize them to better than 1/84000000 seconds, which is simply unacceptable for your purposes.

[minmi]

What if I decided to use two arduino boards but with the same PC connected to both?

[Walter Roberson]

In order for MATLAB to communicate with two arduino boards simultaneously, the two boards would have to be connected to some kind of data controller board that supported triggers to send the data at the same time. Normal communication with arduino is through a serial port or a USB-emulated serial port. MATLAB can only handle one serial port interrupt at a time, so you cannot really synchronize two serial ports. And even if you could, the two arduino would have to run synchronized.

These kinds of tasks are a lot easier to handle if you do not define the two activities as being simultaneous and instead define a maximum time difference between them. Because with a maximum time difference specification you can read documentation and you can test to see if you meet your specification: it gives you something to aim for that might be reachable instead of the impossible "simultaneous".

For example, what is the maximum overtone frequency that you require to be present for your buzzer? If you can achieve synchronization within a time period corresponding to twice that frequency then you have defined that as being "good enough".

[marwa kamel]

" the two boards would have to be connected to some kind of data controller board that supported triggers" Is there any suggestions for that "data controller board"? I need to read from the sensor via serial and write on an arm robot with another serial! Regards

[Walter Roberson]

National Instruments CompacDaq architectures can have a controller that can be configured to send triggers to multiple locations.

However, if you are willing to use serial communications for what you are doing, I can pretty much guarantee that you do not need that degree of synchronization: the sorts of technologies that need that degree of synchronization would require that you synchronize with digital pulses, not with serial ports.

[marwa kamel]

Ok, so how can I send to two serials at the same time as I illustrated the task previously?

[Walter Roberson]

See for example https://www.mathworks.com/examples/daq/mw/daq_product-demo_synchronize_PCI_using_RTSI-synchronize-ni-pci-devices-using-rtsi

Though I would have to research to determine whether NI makes any triggerable serial devices.

Using triggers with serial devices is questionable. Serial devices transfer whatever is queued for them, in FIFO order, with it being up to the device as to what should happen if you ask to queue more samples than the internal FIFO size. If you already have a sample queued and ready to be transmitted for the side you are reading from, then how old is the sample, and if it was queued up already then what is the problem with reading it either earlier or later instead of synchronized with the other device?

If you do not already have a sample queued and ready to be transmitted for the side you are reading from, then some kind of response has to be solicited from the sender in order for it to queue at least one byte to be transmitted, and since the time to do that could be variable, requiring a high degree of synchronization with the other system does not seem to make sense.

I have never seen a serial device for arduino which was a Synch or Bi-Synch device -- only asynch devices. Those do not have tight bit timings, and have the start-bit / data / stop-bit protocol. If you need precise timing, then which of those bits do you need to synchronize on?

Working with a robot arm can be done one of two ways:

1. send the device a command (often multiple bytes long) about the kind of movement it is to undertake, often specifying some kind of destination or some kind of repetition count; Or
2. use a technique such as PWM (Pulse Width Modulation) to send it a whole series of commands, with the phase and amplitudes encoding each rotation or movement "click"

For the second of those two possibilities, you need a whole series of bits and you cannot really encode them as serial port bytes; timing is important for this form, but it is pretty much out of the question to handle this through an asynch serial port.

For the first of the two possibilities, you do not need tight timing on the command because you can pretty much assume that the device is stopped and that the command tells the device how much work to do (some robot arms take in commands in which the commands model that the device is stopped, but the robot arm control systems analyze the sequence and optimize so that they do not need to keep stopping.) So for this first possibility, tight synchronization is not required.

With your mention of two arduino boards, I speculate that the one that has the robot arm controlled is expecting control messages from MATLAB that it is then responsible for decoding and acting on using a PWM output (and sensor inputs.) Considering the time it takes to do the decoding and that it takes variable times to undertake the command, it seems very unlikely to me that you need tight synchronization with whatever the other arudino is handling.