On Tue, 2013-09-10 at 21:34 -0400, Epic Jefferson wrote:
> The modified version of the arduino sketch is included in the .zip in
> my first email if you want to have a go at it. i haven't changed
> anything on the pd side. I would rather sacrifice duty cycle
> resolution and be able to control 64 solenoids, than making the entire
> message longer and slowing down the entire system.

I adapted the bitmask stuff in the the Pd patch and the Arduino sketch
so that 6 bits are used for the pin address. This means, the velocity
has now only 256 steps. Check the attachments.

Beware, I wasn't able to actually test the modifications as I currently
don't have an arduino at hand.

> As far as the dropped messages go, I'm sending separate messages by
> packing the data and sending it to a single [trigger $1 $2{ message
> box. I'll try sending separate messages to see if that helps.

I'm not totally sure if I understand you correctly, but this should be
fine, as long as [solenoiduino] receives 'trigger X Y' messages.

The main difference between your version and mine is that yours uses the
Tlc stuff. I don't know how this part behaves if you set and update
twice in a row very quickly. May be this is the culprit? Just a guess, I
can't test here and I don't have a clue what this code does or if it
does something time critical at all. A cheap work-around might be to
rate-limit the messages on the Pd side.

Regarding the handshake: You may skip that all-together if it doesn't
work for you, as it isn't really necessary. I thought it might be a
convenient way check to make sure the hardware has the correct firmware
loaded. To quickly test send 255 to [comport] and see if you get
something back. If so, the problem might be in the [solenoiduino]
abstraction.

Roman

> On Tue, Sep 10, 2013 at 6:24 PM, Roman Haefeli <reduzent@gmail.com>
> wrote:
>         On Tue, 2013-09-10 at 01:53 -0400, Epic Jefferson wrote:
>         > To control solenoids with dynamics, I adapted Reduzent's
>         > [Solenoiduino] abstraction and arduino sketch to include the
>         TLC5940
>         > functions, which is what the Practical Maker PWM shield is
>         based on.
>         > So far, I'm able to control 44 solenoids using custom
>         drivers and 2
>         > stacked PWM shields. This is an excellent alternative if you
>         want to
>         > build a relatively cheap electro-mechanical piano setup.
>         >
>         >
>         > The problems i've run into:
>
>         >      1. if 2 or more messages get sent simultaneously, one
>         of them
>         >         might get dropped (this happens a lot)
>
>
>         This shouldn't happen and actually never happened in my own
>         experience.
>         A single 2-byte message sets and one pin to HIGH and sets a
>         timer for
>         that pin. So, if you need two set two pins simultaneously, you
>         need to
>         send two 2-byte messages. I don't see how the code could omit
>         a message,
>         unless two subsequent messages set the same pin.
>
>         If you modified the code, you can send me a copy, so I'll look
>         into it.
>
>         >      1. the handshake does not seem to work on Linux (Ubuntu
>         11)
>
>         It's pretty crude. Whenever you send it a '255' (0xff) byte,
>         it responds
>         with the following ASCII sequence: 'SOL 0 1'. You can easily
>         test that
>         with [comport] directly.
>
>         The ugly thing is that [solenoiduino] has to make sure not to
>         send any
>         0xff bytes and thus some values for periods are not allowed /
>         replaced,
>         e.g 127, 255, 383 etc.
>
>         >      1. the original code only supports 16 solenoids
>         > This last one is the one that goes over my head, since the
>         code uses
>         > that bit twiddling stuff, I can't figure out how to send the
>         > appropriate messages to any solenoids past 15. So, I'm a
>         little stuck
>         > here, any help?
>
>
>         The solenoiduino code uses two bytes per message, while the
>         first bit of
>         each is used for defining the byte order. This leaves 14 bits
>         for the
>         payload. The current implementation uses 4 bits for the pin
>         address and
>         10 bits for the duty cycle. If you can live with a lower duty
>         cycle
>         resolution, you can shift some bits around. For instance, you
>         could
>         adapt the bitmask to use 6 bits for the address (allows to
>         control 64
>         solenoids) and use only 8 bit for the velocity / duty cycle.
>
>         Alternatively, you could extend the protocol to use 3 bytes
>         per message.
>         This would give you a payload of 21 bits to be distributed
>         between
>         address and duty cycle. Of course, this reduces your maximum
>         message
>         rate by 1.5.
>
>         Roman
>
>
>
>
>
>         _______________________________________________
>         Pd-list@iem.at mailing list
>         UNSUBSCRIBE and account-management ->
>         http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> --
> www.epicjefferson.com
> www.avmachinists.org Puerto Rico based Art Collective/ Non-Profit Org

_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list