<div dir="ltr">Awesome, thanks! <div><br></div><div>i tested it quickly and i can now address all of the solenoids from within pd. </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 11, 2013 at 6:26 PM, Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, 2013-09-10 at 21:34 -0400, Epic Jefferson wrote:<br>
> The modified version of the arduino sketch is included in the .zip in<br>
> my first email if you want to have a go at it. i haven't changed<br>
> anything on the pd side. I would rather sacrifice duty cycle<br>
> resolution and be able to control 64 solenoids, than making the entire<br>
> message longer and slowing down the entire system.<br>
<br>
</div>I adapted the bitmask stuff in the the Pd patch and the Arduino sketch<br>
so that 6 bits are used for the pin address. This means, the velocity<br>
has now only 256 steps. Check the attachments.<br>
<br>
Beware, I wasn't able to actually test the modifications as I currently<br>
don't have an arduino at hand.<br>
<div class="im"><br>
> As far as the dropped messages go, I'm sending separate messages by<br>
> packing the data and sending it to a single [trigger $1 $2{ message<br>
> box. I'll try sending separate messages to see if that helps.<br>
<br>
</div>I'm not totally sure if I understand you correctly, but this should be<br>
fine, as long as [solenoiduino] receives 'trigger X Y' messages.<br>
<br>
The main difference between your version and mine is that yours uses the<br>
Tlc stuff. I don't know how this part behaves if you set and update<br>
twice in a row very quickly. May be this is the culprit? Just a guess, I<br>
can't test here and I don't have a clue what this code does or if it<br>
does something time critical at all. A cheap work-around might be to<br>
rate-limit the messages on the Pd side.<br></blockquote><div> </div><div>I think it might be correct to assume that the dropped messages could be on the Tlc side of things, </div><div>i have a feeling that while it's setting and updating, any incoming message could be lost.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regarding the handshake: You may skip that all-together if it doesn't<br>
work for you, as it isn't really necessary. I thought it might be a<br>
convenient way check to make sure the hardware has the correct firmware<br>
loaded. To quickly test send 255 to [comport] and see if you get<br>
something back. If so, the problem might be in the [solenoiduino]<br>
abstraction.<br></blockquote><div><br></div><div>this is a small problem, for some reason sending an 'open X' type message to solenoiduino doesn't bang the '255' message box. i have to click on it myself for it to work, wierd. Now that i think of it, the new max velocity is 255, is it possible the arduino could interpret this as trying to establish a connection again and not as the 'velocity' byte? I haven't noticed a problem but i haven't tested it properly yet. I might opt for removing the handshake entirely</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Roman<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On Tue, Sep 10, 2013 at 6:24 PM, Roman Haefeli <<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>><br>
> wrote:<br>
> On Tue, 2013-09-10 at 01:53 -0400, Epic Jefferson wrote:<br>
> > To control solenoids with dynamics, I adapted Reduzent's<br>
> > [Solenoiduino] abstraction and arduino sketch to include the<br>
> TLC5940<br>
> > functions, which is what the Practical Maker PWM shield is<br>
> based on.<br>
> > So far, I'm able to control 44 solenoids using custom<br>
> drivers and 2<br>
> > stacked PWM shields. This is an excellent alternative if you<br>
> want to<br>
> > build a relatively cheap electro-mechanical piano setup.<br>
> ><br>
> ><br>
> > The problems i've run into:<br>
><br>
> > 1. if 2 or more messages get sent simultaneously, one<br>
> of them<br>
> > might get dropped (this happens a lot)<br>
><br>
><br>
> This shouldn't happen and actually never happened in my own<br>
> experience.<br>
> A single 2-byte message sets and one pin to HIGH and sets a<br>
> timer for<br>
> that pin. So, if you need two set two pins simultaneously, you<br>
> need to<br>
> send two 2-byte messages. I don't see how the code could omit<br>
> a message,<br>
> unless two subsequent messages set the same pin.<br>
><br>
> If you modified the code, you can send me a copy, so I'll look<br>
> into it.<br>
><br>
> > 1. the handshake does not seem to work on Linux (Ubuntu<br>
> 11)<br>
><br>
> It's pretty crude. Whenever you send it a '255' (0xff) byte,<br>
> it responds<br>
> with the following ASCII sequence: 'SOL 0 1'. You can easily<br>
> test that<br>
> with [comport] directly.<br>
><br>
> The ugly thing is that [solenoiduino] has to make sure not to<br>
> send any<br>
> 0xff bytes and thus some values for periods are not allowed /<br>
> replaced,<br>
> e.g 127, 255, 383 etc.<br>
><br>
> > 1. the original code only supports 16 solenoids<br>
> > This last one is the one that goes over my head, since the<br>
> code uses<br>
> > that bit twiddling stuff, I can't figure out how to send the<br>
> > appropriate messages to any solenoids past 15. So, I'm a<br>
> little stuck<br>
> > here, any help?<br>
><br>
><br>
> The solenoiduino code uses two bytes per message, while the<br>
> first bit of<br>
> each is used for defining the byte order. This leaves 14 bits<br>
> for the<br>
> payload. The current implementation uses 4 bits for the pin<br>
> address and<br>
> 10 bits for the duty cycle. If you can live with a lower duty<br>
> cycle<br>
> resolution, you can shift some bits around. For instance, you<br>
> could<br>
> adapt the bitmask to use 6 bits for the address (allows to<br>
> control 64<br>
> solenoids) and use only 8 bit for the velocity / duty cycle.<br>
><br>
> Alternatively, you could extend the protocol to use 3 bytes<br>
> per message.<br>
> This would give you a payload of 21 bits to be distributed<br>
> between<br>
> address and duty cycle. Of course, this reduces your maximum<br>
> message<br>
> rate by 1.5.<br>
><br>
> Roman<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> <a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -><br>
> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
><br>
><br>
><br>
><br>
> --<br>
> <a href="http://www.epicjefferson.com" target="_blank">www.epicjefferson.com</a><br>
> <a href="http://www.avmachinists.org" target="_blank">www.avmachinists.org</a> Puerto Rico based Art Collective/ Non-Profit Org<br>
<br>
</div></div><br>_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="http://www.epicjefferson.com" target="_blank">www.epicjefferson.com</a><br><a href="http://www.avmachinists.org" target="_blank">www.avmachinists.org</a> Puerto Rico based Art Collective/ Non-Profit Org
</div></div>