[PD] modifying Reduzent's [Solenoiduino] to control 44 solenoids (electro-mechanical piano)

Epic Jefferson jeffreyconcepcion at gmail.com
Wed Sep 11 03:34:47 CEST 2013


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.

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.


On Tue, Sep 10, 2013 at 6:24 PM, Roman Haefeli <reduzent at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130910/e1a10d4d/attachment.htm>


More information about the Pd-list mailing list