# Help debugging

**URL:** <https://mworks.discourse.group/t/help-debugging/169>\
**Category:** Support\
**Created:** [July 29, 2020, 8:43pm UTC](https://mworks.discourse.group/t/help-debugging/169 "2020-07-29T20:43:03Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [July 29, 2020, 8:43pm UTC](https://mworks.discourse.group/t/help-debugging/169/1 "2020-07-29T20:43:03Z")

</div>

Hey Chris,

We are encountering somewhat rare, but critical, bugs in our Mworks code.

Background:  
We use pin 12 on an Arduino device connected via Firmata bluetooth to drive a fluid delivery circuit. When it is high, the circuit runs a DC current through a pump that delivers fluid continuously. When it is low, no current flows through the pump, and it is inactive.

The bug:  
While the task is running, every once in a while, the pump dispenses water continuously for an extended length of time. It then stops at some point.

Observations:

- The bug has been observed to start while the subject is doing trials.
- Stopping the experiment and performing a reload of the .mwel immediately ceases the bug.
- The bug has occurred across 3 different circuits in 3 different rigs.
- So, it seems unlikely it is due to a hardware bug.

My speculations on source of bug:  
I think this has to do with the Firmata interface.

We request that pin 12 is set to high through a variable assignment (see code below). My guess is that the first assignment (pump\_control\_line = true) succeeds, but the second assignment and third assignment both fail.

The monkey then stops working, as the water is flowing continuously. If the monkey happens to do another trial, one of the pump\_control\_line = false assignments eventually succeeds, and correct code behavior resumes. My guess is this bug could happen more frequently than we have observed because of this.

This seems related to another behavior we have previously observed (and I have brought up with you earlier at some point, I think), which is that setting cur\_reward\_duration\_ms to values around ~25 msec causes the juicer to sporadically fail to dispense juice, which can be explained by a failure of setting pin12 to high pump\_control\_line = true (as it is overrided by pump\_control\_line = false).

In our case, it’s really important that we can verify that the juicer circuit is engaged as requested. One proposal is to rewrite the Arduino interface + the firmware running on the Arduino itself, so we have the ability to send encoded pin commands (e.g., set pin 12 to high for 50 ms, then turn off), instead of trying to encode pin commands on the Mworks side. Even better to also have mworks be able to receive messages from the Arduino and verify that a pin request has succeeded before resuming mworks code.

Any workarounds would be appreciated too.

Thanks,  
Michael

‘’’

firmata pump\_output\_device (  
bluetooth\_local\_name = bluetooth\_local\_name  
autostart = YES  
//reconnect\_interval = 5s // Not supported in current mworks version?  
//connected = pump\_connected  
){  
firmata\_digital\_output (  
pin\_number = 12  
value = pump\_control\_line  
)  
}

var reward = 0 {  
if (reward \> 0){  
play\_sound (reward\_sound)  
pump\_control\_line = true  
wait (  
duration = cur\_reward\_duration\_ms  
duration\_units = ms  
)  
pump\_control\_line = false  
total\_msec\_pump\_on = total\_msec\_pump\_on + reward\_duration\_ms  
report(‘Reward! ( $reward\_duration\_ms msec )’)  
}

pump\_control\_line = false  
}  
‘‘’

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [July 29, 2020, 9:11pm UTC](https://mworks.discourse.group/t/help-debugging/169/2 "2020-07-29T21:11:21Z")

</div>

Hi Michael,

I’m surprised that the message to set the pump control line low is being lost, but I agree that it’s the most likely explanation of the problem. I also agree that the on/off timing should be handled on the device, not in MWorks. This would also let you avoid the [timing issues associated with Bluetooth LE](https://mworks.tenderapp.com/discussions/problems/429).

Let me think about the best way to handle this. Be aware that, whatever solution we devise, you will definitely need to install new firmware on the Arduino boards, so you’ll need to be able to get them out of their boxes (or at least expose them enough to connect a USB cable).

Cheers,  
Chris

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [July 30, 2020, 12:17pm UTC](https://mworks.discourse.group/t/help-debugging/169/3 "2020-07-30T12:17:20Z")

</div>

Thanks Chris. Not a problem, it’s easy to access the Arduino boards.

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [August 7, 2020, 1:18pm UTC](https://mworks.discourse.group/t/help-debugging/169/4 "2020-08-07T13:18:55Z")

</div>

Hi Michael,

Just a quick update:

I’ve worked out the changes needed in the Firmata protocol, and I’m now implementing them in both the Firmata firmware and MWorks. I’ll let you know as soon as they’re ready for testing.

Cheers,  
Chris

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [August 7, 2020, 1:20pm UTC](https://mworks.discourse.group/t/help-debugging/169/5 "2020-08-07T13:20:35Z")

</div>

Great. Thank you!

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [August 18, 2020, 8:36pm UTC](https://mworks.discourse.group/t/help-debugging/169/6 "2020-08-18T20:36:30Z")

</div>

Hi Michael,

I’ve finished implementing my changes in the Firmata firmware and MWorks.

MWorks now supports two new channel types for Firmata devices. The one you’ll be most interested in is the [digital output pulse channel](https://mworks.github.io/documentation/latest/components/firmata_digital_output_pulse_channel.html). This looks a lot like a regular digital output channel. The difference is that you assign durations to the [value](https://mworks.github.io/documentation/latest/components/firmata_digital_output_pulse_channel.html#value) parameter. Every time you make an assignment, MWorks sends a pulse request to the Firmata device. The device then sets the channel’s associated pin high, leaves it on for the specified duration, then resets it to low. By using a pulse output channel, you can both (1) eliminate the need to manually set the pin back to low via MWorks and (2) avoid the [timing limitations](https://mworks.tenderapp.com/discussions/problems/429) associated with the BLE connection.

The second new channel type is the [digital input pulse channel](https://mworks.github.io/documentation/latest/components/firmata_digital_input_pulse_channel.html). As you can probably guess, this channel type watches for pulses on an input pin (i.e the pin going from low to high and back to low) and reports the duration of each pulse. As with output pulse channels, the pulse timing is measured entirely on the Firmata device, and MWorks is notified by a single message when the pulse completes. I added this channel type mostly for symmetry and to aid my own testing. However, it could be useful to you as a means of confirming that juice has been delivered. Specifically, I’m thinking you could connect the juice control output pin to both the juice pump _and_ an input pin on the Firmata board. If you then configure that pin as a pulse input channel, you’ll receive measured “juice on” durations in MWorks. If your experiment waits for these, then it can confirm that the pump was on for the expected duration.

To make use of these new channel types, you’ll need to install the new [Firmata library with MWorks extensions](https://github.com/mworks/mworks-firmata-arduino) on your boards. I’ve updated the [setup instructions](https://mworks.tenderapp.com/kb/io-devices/setting-up-an-adafruit-feather-m0-bluefruit-le-as-a-firmata-device) to use this library. (Note that it strictly adds features to the standard Firmata library, so you’re free to install it on your boards and use it with older MWorks versions that don’t support the new channel types.)

You’ll also need an updated MWorks version. To try things out on a Mac, you can use the current [nighty build](https://mworks.github.io/downloads/). To get it on your iPad’s, you have a couple options. First, I’m hoping to release a new, “official” version of MWorks in the next couple weeks (though I can’t make any guarantees on the timing). If you can wait for that, then you can just update MWorks from the App Store once the release is out.

Alternatively, if you want to use the new Firmata features ASAP, I can create an [ad hoc distribution](https://help.apple.com/xcode/mac/current/#/dev7ccaf4d3c) for you. This isn’t hard, but it requires me to register the [device ID](https://help.apple.com/xcode/mac/current/#/dev93ef696c6?sub=devdfa32588f) for every iPad on which MWorks will be installed. You would need to provide me with the device ID’s beforehand. Once I create the ad hoc build, I’d share the IPA file with you via Dropbox. You’d then have to [install it](https://help.apple.com/xcode/mac/current/#/devade83d1d7) using Xcode or Apple Configurator 2, both of which are available from the Mac App Store.

Please let me know how you’d like to proceed.

Cheers,  
Chris

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [August 18, 2020, 8:48pm UTC](https://mworks.discourse.group/t/help-debugging/169/7 "2020-08-18T20:48:03Z")

</div>

Hi Chris,

Thank you, the changes look like they’ll resolve the issue nicely.

I will wait until the App Store publishes the latest iOS build, and will test this out on my setup then.

Michael

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [September 9, 2020, 3:02pm UTC](https://mworks.discourse.group/t/help-debugging/169/8 "2020-09-09T15:02:04Z")

</div>

Hi Michael,

The new version of MWorks is [now available](https://mworks.github.io/news/2020/09/08/0.10-released/).

Cheers,  
Chris

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [July 19, 2022, 7:40pm UTC](https://mworks.discourse.group/t/help-debugging/169/9 "2022-07-19T19:40:50Z")

</div>