Can I bypass enforced Control Center limits?

Support Servo controllers and servos
1

Hi, folks! I’m using servo positioning settings to control ShiftBrites and ShiftBars+Satellite001s, much like you do in the manual example for digital output where you use servo positioning settings as variables from which you take bit patterns. I’ve cranked the Channel Setting’s Min and Max to their limits, 64 and 4080 respectively, but whereas those are generous limitations for protecting real servos, they don’t allow me to fully dim or fully brighten my LEDs. A setting of 0 means no PWM pulses for servos, but a setting of 1 resolves to a setting of 64 in the Control Center (ignoring for now what that really means in microseconds and that the setting is really 4 times 64). How can I get full 14-bit control over each channel with the understanding that if I hooked a servo to that channel I’d wreck it? I want to set a pretend position of, for example, .25 in the Control Center’s Status tab’s Position value for device 0’s channel 3. The Control Center (or probably, actually, the Maestro itself) won’t let me. Neither can I do it by sending 0xAA 0x0 0x4 0x3 0x1 0x0 from my computer. If I just can’t, right now, how 'bout adding a command other than but similar to 0x04 for servo positioning-- call it, say, variable setting-- with all the necessary caveats your lawyers can think up? And also maybe you can provide a way to do the same from a script. My scripts need to set and read every possible value from 0 to 16383 into a channel set up for servo positioning. Or–! Maybe you could add a fourth functionality to channels: One can set them as Servo, Input, Output or Variable! That would be cool! In Variable mode all 14 bits are functional, and the newbies aren’t going to ignore ‘Servo’ and hook their servos to channels set to ‘Variable.’ Thanks!

Loren

2

Hello,

We do not have the example you are referring to in the manual. Were you talking about this forum post? And why do you want 14 bits of data to control ShiftBrites (they only have 10-bits of brightness for each color)? Are you aware of the serial commands that let you send a (14-bit) parameter to a subroutine in your script? It is possible that you could do it by setting the channel to an output and using some low-level USB commands through the Pololu USB SDK to bypass the channel maximum, but I am not sure that it is going to be worth the effort for you.

Serial-accessible variables are certainly one of the things that we would like to add to the Maestro some day, but that some day might be pretty far off.

-Paul

3

Hi, Paul! It’s always a pleasure to hear from you, Jan or David! You’re right, the manual’s Digital Output sample script just suggested some literal values ("# example usage: 1023 511 255 rgb") and that post you cited expanded on the code provided with the variables in channels 3, 4 and 5, which is what I was referring to. Good job! You then ask, “And why do you want 14 bits of data to control ShiftBrites (they only have 10-bits of brightness for each color)?” You’re right, they do-- times 3 colors, which is 30 variable bits a given script needs to shift my desired color register state out to a ShiftBrite/ShiftBar. I’ll explain my desire for 14 bits in a moment, but first you go on to ask, “Are you aware of the serial commands that let you send a (14-bit) parameter to a subroutine in your script?” I’m aware of one, command 0x28, Restart Script at Subroutine with Parameter. That’s 14 bits per script call. So we’re shy quite a few bits to control a ShiftBar/ShiftBrite in a single script. Hence the excellent idea of using servo channels as variables, but when the Maestro changes bit patterns 00000000000001 through 00000000111111 into bit pattern 00000001000000 to protect my servos, the range of useful bits is really only 00000001000000 through 11111111000000 (64 through 4080). That’s only 8 bits of usefulness! As you say, we need 10 bits per color, so we’re still stuck with ShiftBrites/ShiftBars that can’t turn very dim or fully bright if we make one channel correspond to one color. That’s why I want a Variable mode to pass 14 bits per channel. I’d use the extra four bits as control flags for my ShiftBar/ShiftBrite script, and for any number of other kinds of scripts-- that is, if you give me the bits, I’ll put them to good use! If you create a Variable mode, why go from 8 useful bits to 10 when you can go from 8 to 14? We can use four channels (that’s 32 useful bits) per ShiftBar/ShiftBrite. But that would use up a 12-channel Mini Maestro for only two ShiftBars/ShiftBrites (we need three output channels for DATA, CLOCK and LATCH), assuming one script to control both at once . Not bad, but not a terrific lightshow… However, using each channel’s eight useful bits as an argument variable for a corresponding light, augmented by the 14-bit parameter you mentioned if need be, we can access any one of many hundreds of canned light patterns in the generous 8K of Flash the Maestro’s PIC provides and still have room for the processing subroutines. I wrote such a script (saving the passed parameter for something else) where I can send any one of up to 256 desirable patterns each to up to 9 ShiftBars/ShiftBrites on a 12-channel Maestro on a single script call. A better show! Unfortunately I can’t use the speed and acceleration parameters for the servo channels to modify my light settings, since they’re not really settings, but 8-bit variables. What would be cool is to have a serial script command like the serial servo command 0x1F, Set Multiple Targets. Expanding command 0x28, Restart Script at Subroutine with Parameter, it could push multiple values onto the stack for me, like arguments in a function call. Have you folks considered something like that? Then I could push the values I want into the channels and use the features of the Maestro on them as channels, not variables. That would be GREAT!

You mentioned that, “It is possible that you could do it by setting the channel to an output and using some low-level USB commands through the Pololu USB SDK to bypass the channel maximum, but I am not sure that it is going to be worth the effort for you.” That’s an interesting thought, but I haven’t a clue how to proceed with that. I’ll give it some serious consideration, and have another look at the SDK! Great idea, Paul, as always. It’s sure worth my effort. I’m planning to sell systems that have many servos and up to twelve ShiftBrites or ShiftBars/Satellite001s going all at once in a nicely integrated package. Except that I can’t gradually change light colors, I’m there now with one 18-channel Maestro for the lights and lots of 12-channel Maestros serially connected to it for the servos! So push my requests onto your corporate stack of requested features, would you please? Thanks so much!

Loren

4

Hello,

Your logic about 64us to 4080us only being 8 useful bits is wrong in two ways. First, you are off by a factor of four, since the actual values are in units of 0.25us - numerically they are from 256 to 16320. Then, this is clearly not quite 14 bits, but it is certainly more than 13. For example, if you just consider values from 256 to 256+8191, you can get a 13-bit number from each channel by simply subtracting 256. The example I linked to really does do full 10-bit control of the ShiftBrites, not just the 8-bit control that you are talking about. Can you take another look at that example and make sure that you understand it?

-Paul

5

Hello, Paul,
Yeah, I goofed up. I showed 11111111000000, which is 16320 base 2, and mistakenly called it 4080. You read the familiar numbers 64 and 4080 and thought I’d failed to multiply by 4, a common mistake in this forum. I compounded my mistake by getting one of my binary numbers wrong. I don’t blame you for it, but I think you missed my point. Relative to the Control Center, all values from 1 to 63.75, that’s 00000000000001 through 00000011111111 relative to the script AFTER multiplying by 4, are adjusted upward to 64.0, that’s 00000100000000 AFTER multiplying by 4, thanks to Min. Right so far? And all values above 4080 * 4 = 16320, that is, 11111111000001 through 11111111111111, are adjusted downward to 11111111000000, thanks to Max, right? I can’t get 10 contiguous bits out of any 10 bits when I only consider 10 bits, because of Min and Max. The rest of your response simply commandeered an eleventh bit when you questioned my logic. But I was only discussing using ten bits. So let’s clarify:

The example you linked to uses the ten low-order bits. Remember how it takes the channel position from a given channel 3 through 5, then pushes 512 (1000000000) onto the stack as a bitmask and shifts right from there in a loop, using bitwise_and to examine the bit at 512, then 256, then 128 and so on down? The sample does not advise as to the range of position settings that are useful for that sample, or that some settings don’t work right because of Min and Max. Assume for a moment that I’ve set the channel to (63.5 * 4) = 254 = 11111110 in an attempt to achieve a dimmed color brightness in only 10 bits, wanting to conserve the high-order four bits for essential flags and other purposes. I fail; I get the brighter 100000000, which is as dim as I can go except for off. Because of the Min limitation of the Maestro, displayed as 64.0 in the Control Center but actually-- and I DO understand this, Paul, my goof-up above to the contrary-- 4 times higher, or 256, it can never get a value lower than 0100000000 when the Control Center’s channel setting is below 64.0. I started this thread because I want to dedicate ten contiguous bits, and no other bits, to defining a color, and therefore wish to have a variable value where I can use any or all of the 14 bits as I please. In this instance I want the ten low-order bits for color information and the upper four bits for something else. But I can’t because of the Min limit. .

You are, of course, correct that I can get ten contiguous bits if I introduce an offset, which is to say, set one of the four high-order bits of the position setting to 1 as an eleventh bit of the light color setting. To get 1111111111 as the low-order ten bits, I need one or more of the 4 high-order bits set 00011111111111 through 11111111111111. It would appear I have to lose one of my flag bits, which you can tell from the above discussion I don’t like being forced to do. That’s what this thread is about-- defeating Min and Max in the Control Center, in the Maestro, or both. You’ve said there may be a way through the SDK, and that serial variables may come some faraway day from now. Good, and good. Meanwhile, what occurs to me is that I don’t necessarily need to fully dedicate one of the four high-order bits as an eleventh bit, I can still use all four of them as flags. I just have to be sure at least one of the four flags is set any time I supply a color value to a servo positioning channel, but not all four flags so that the total value will never exceed 16320. In any case, any workaround in this particular instance does not in any way weaken my argument before Pololu for the usefulness of a full 14-bit variable. I’m certainly not contradicting your assumption that I can or want to use an eleventh bit, or should infer the use of one from the sample script you linked to. When using ShiftBars/ShiftBrites, most people probably dedicate the whole servo positioning channel “variable” just for setting light color and thus have four bits to spare. I do wish you’d consider my Variable ideas, especially the one about pushing multiple parameters on the stack when calling a script so we don’t have to use servo positioning channel settings as script variables that may be automatically adjusted upward to 256 or downward to 16320. That would only require some code-changes in the Maestro’s PIC the next time you program a batch of them, and some documentation changes. You do make firmware and documentation changes now and again! I for one am doing a lot of diverse things with the Maestro, and am sure 'many other users are too. I want to be able to pass more than one variable, up to 14 bits each, and doing it directly into the script like I can the one parameter now would be ideal. Thanks again,

Loren

6

Hello,

I do not understand everything you are saying, but do you agree that you can get 13 full bits of data by using numbers between 256 and 256+8191?

If you want a “terrific light show”, I recommend that you use a Micro Maestro with serial commands to call the send_10_bit_value subroutine. You should be able to send data to that subroutine about as fast as the Maestro will be able to send it out to the ShiftBrites anyway, so there is no reason for the Maestro to do any of the data processing.

-Paul

7

Hi, Paul,

Yes, I certainly agree, you can get 13 bits out of that range.

Can you give us some idea how the Maestro interleaves serial input, PWM and script handling? In my opinion as a PIC programmer, the Maestro is really remarkable because of all the different things you’ve got it doing at once. Can you tell me, in general terms, of course, if the Maestro is polling serial input and using an interrupt for PWM output and scripting, or running any script and using an interrupt for serial input and another for PWM? I’d like to deduce what it is doing most of the time. I could pour serial color data to servo position channels and let a script in an infinite loop shift them out with the send_10_bit_value subroutine. That’s restating you suggestion above, isn’t it? But I’m thinking if the script is running in the foreground and everything else is done by interrupt, it might be more efficient to make the Maestro do more of the work through the script. What do you think? Thanks,

Loren

8

Hi Loren,

I do not want to go into too much detail, but we definitely use interrupts for the servo pulses, since we want them to be as precisely-timed as possible. Why would the general structure of the code matter? I think that most of the slowness by far will come from your script having to slowly shift those bits out to the ShiftBrites, and anything extra that the script has to do is just going to slow it down more.

-Paul

9

Hi, Paul,

The structure of the code only matters so I can make the most out of idle time, as if the Maestro has much! Slowness matters, but so does channel consumption. Using one servo channel per color per ShiftBrite means that in a 12-channel Maestro using three output channels I can get three ShiftBrites to blend from any color to any color, which is nice. But using a lookup table in the Maestro and some math, I can (and do) store 512 (8^3) 3-color patterns. Each channel (acting like a passed parameter) calls for a pattern. So I can control nine ShiftBrites for 512 color patterns (that’s down some from the billion+ possible, and is, alas, without the desirable blending the channels can provide) with some script-intensive code. If that script-processing time is otherwise idle time waiting for interrupts I’ve got a pretty good idea here for my lightshow. But if the Maestro is going to get bogged down, say, polling for serial input AND trying to run an 8-K script (with the table, I’m about twenty bytes short of 8192 bytes!), then I need to offload the work to the computer and commit to one color per channel. I’ll actually use one 12-, 18- or 24-channel master Maestro for lights depending on which system I sell, so I can get 3 to 7 ShiftBars/Satellite001s to work wonderfully or 9 to 21 of them to work okay depending on how the Maestro is impacted by my script. Processing speed DOES matter because I have to roughly (half a second?) synchronize the lights to servos running off other remote Maestros chained to the master by UART. I’m asking a lot of the Maestro, and it is delivering brilliantly. So-- no trade secrets, of course, but is the script interrupted by everything else? I hope so. You were very wise to ensure the servo pulses are precisely timed. That’s why the Maestro is jitter-free, which is really great for me and every customer. Thanks, Paul!

Loren

10

Hello,

The Maestro script should not be slowed down significantly by USB communication, if you just send positions once in a while (every few milliseconds.) If you are using the chaining feature to send data continuously to a bunch of remote Maestros, that could slow down the script, so you would want the script to be as simple as possible - and the simplest possible script just takes 10 bits passed in by a serial command and sends it out.

So…I continue to believe that if you send 10 bits of data at a time using a serial command, you will be able to send whatever colors you want to as many ShiftBrites as you want, as fast as the Maestro is capable of doing it. I see no reason to do it any other way.

-Paul