Make controller connects and disconnects

Hi,

I am trouble shooting a project I am working on.  Right now I am using AS3 and the digital outs on the make controller to pulse a bipolar step motor driver.  However, when the code is executing the make controller event listeners are reporting the board connecting and disconnecting...usually after a few cycles of the code, but not in a pattern.  MC Helper does not show the board disconnecting after it has initially connected.  I am using an external class to connect the board.  Am I missing something?....I am really not sure what is going on....can anyone help?  Thanks.

Chris

The only visual cue that mchelper will give that a Controller has gone away is that it will be removed from the list of Controllers on the left hand side. Usually what that means is that the board is crashing and rebooting. Is the frame rate of your movie super high? Have you experimented with using other systems on the board other than digital outs, just to see if it's specific to the digital outs?

The frame rate is high (30/sec)...but not unreasonable.  I have used the analog inputs with max/msp and they worked, and I tried out the LED examples for flash which did not work.  I am currently reinstalling heavy to see if that helps.....any other ideas?...thanks.

Previously Liam Staskawicz wrote:

The only visual cue that mchelper will give that a Controller has gone away is that it will be removed from the list of Controllers on the left hand side. Usually what that means is that the board is crashing and rebooting.

Might it be worthwhile to have another indication?  I have a routine which PWMs an LED (the heartbeat LED, in my case), ramping up or down, which I use to tell me that some fatal thing (like an unhandled exception) has happened.  It is visually distinct from flashing.  Maybe the normal boot process could include such a ramp so that if the controller is cyclically rebooting, it would be obvious.  My implementation uses a spin loop for timing, so it would lengthen the boot process, but the sequence only needs to be half a second long or so.

Previously Chris wrote:

any other ideas?...thanks.

Relating to Liam's question about digital outputs, if the problem goes away when you don't use them, one thing I'd suspect is power.  If you're using the onboard 5V regulator to power your motor, noise/sags could be feeding back through the power system enough to upset regulation and reset the controller.  If that's the case, the solution would be to power the motor separately through VExt.

If you're powering the MC from USB instead of a 9-12V supply, the load of the motor could be telling the USB hub that the current budget has been exceeded and causing it to reset the port.  You should be using the 9-12V supply when using motors of any nontrivial size.

Either scenario could be marginal enough to appear random.

Previously Lou Deluxe wrote:

You should be using the 9-12V supply when using motors of any nontrivial size.

... if you're using board power instead of VExt to power the digital outs.

I have done more testing and I uploaded the firmware again.  All other systems on the board seem to be working properly.  From the digital outs, all I need is a 5v pulse in a specific sequence indicating step+, step-, direction+, and direction-.  I am not using the board or the vext to power the motor.  I have a seperate power supply and motor driver board, however I need to pulse the driver board with the previously mentioned sequences to get the motor to move.  I have the vext out powered with an external power supply to ensure the 5v.  The board is powered using the USB.  I occasionally get some movement from the motor and when I first run the actionscript program after connecting the board, it sometimes does not disconnect, but after a few uses it will begin having the problem of disconnecting and reconnecting again.  Any other suggestions.....I really can't figure out what is wrong.  Thanks in advance.

Chris

Yeah, that usage of the digital outs is unlikely to cause rebooting.

Another common cause of reboots is stack overflow.  Try increasing the stack allocations for your threads.

Would I do that through stack audit and debug?...sorry I am not familiar with that......I appreciate the help.

Chris

When you create a task, you specify a stack size as one of the arguments.  That argument is what I'm suggesting you bump up.

Unfortunately, there is no real way to audit stack usage that I know of.  I think there's a compile-time define to make the controller flash a code or something when stacks overflow, but that check takes time, even during normal operation, so most folks probably don't have that set.  And, of course, it's not guaranteed to catch a problem before it crashes things.

So folks usually just try arbitrarily large stack sizes, and, if they want to reduce them later, do so until stuff starts crashing.  It's not very scientific, but without a proper MMU, it's something we've got to deal with.

With the aforementioned stack checking defined (I think the stack patterning depends on that feature being enabled), there may be a way to see the current stack usage of a thread at runtime if it hasn't already overflowed.  I don't know, as it's been awhile since I reviewed the code, but it is something that is possible.  If that does exist, and you have a way of getting the information to where you can see it, that might help you in reducing your stack sizes.  It would only be a yardstick, of course, as stack usage has a way of being a bit variable.

Ok....so I cleaned up the firmware a bit by commenting everything out other than the USB, Digitalout, and OSC......I increased the heap size.  I am still having the issue of disconnecting and reconnecting, however it is in a pattern.  It disconnects after each time I send it an OscBundle.  I have no custom code in the firmware at the moment....I am just using what was already there and then using Actionscript to send instructions.  Below is the Actionscript code I am using to send the bundle:

public function testDir(event:TimerEvent) {
            var myOscBundle:Array = new Array( );
            var i:int;
            if (i>0) {
                trace("null movement");
            }
            else if (i==10) {
                i = 0;
            }
            else {
            for (i = 0 ; i<10 ; i++) {
                myOscBundle.push( new OscMessage( "/digitalout/1/value", [1] ));
                myOscBundle.push( new OscMessage(  "/digitalout/3/value", [1] ) );
                myOscBundle.push( new OscMessage( "/digitalout/3/value", [0]  ) );
                myOscBundle.push( new OscMessage( "/digitalout/1/value", [0] ) );
                mcCon.mcflash.sendBundle( myOscBundle );
            }
           }
        }

It is on a timer, at the moment, to run the function every 3 seconds for 5 cycles

I am not exactly sure how to increase the stack size or the memory allocation for the usb and the digital outs.....my goal is to be able to run this motor consistently with a motion tracking program, but it keeps disconnecting so I can't even begin to program the pulse sequences for the motor past this above simple test.  Even if the for loop is increased the motor twitches the same amount....I am assuming it is because the usb disconnects while it is sending information.   Can anyone help?....this problem is beyond me.  Thanks in advance....sorry for the continuing issue.

Chris

Chris

not sure that it matters, but the connecting/disconnecting usb issue has been happening on a mac pro desktop with leopard os...haven't had a chance to test on a pc....or older operating system.

Previously Chris wrote:

Ok....so I cleaned up the firmware a bit by commenting everything out other than the USB, Digitalout, and OSC......I increased the heap size.  I am still having the issue of disconnecting and reconnecting, however it is in a pattern.

Is the pattern new, or has it always been there and you've not noticed it previously?  IOW, do you think the above changes altered anything?

It disconnects after each time I send it an OscBundle.  I have no custom code in the firmware at the moment....I am just using what was already there and then using Actionscript to send instructions.

Ah.  So that's what AS3 means in your original post.  Yeah, the stack thing is pretty much moot for you, then.

It should just work, but then you know that.  I'll have to rely on someone else to step in here, as I'm out of ideas.

I suppose you could try sending the messages individually (not in a bundle).  It might be slower, depending on the implementation, but if that also causes the resetting, at least it suggests that bundling, itself, might be related to the problem.

There is another thread in this forum which relates to bundling.  There are a whole lot of differences, but what it does suggest is that bundles might have to fit into one packet.  In that thread, it was a UDP packet.  The buffer size for the USB endpoint is even smaller.  Maybe a buffer is being overrun somewhere, corrupting pointers, stack, etc. somewhere adjacent to it.  Bugs could be anything.  I'd class being able to send data, malformed or otherwise, to the device and have it reset (aside from an intentional reset command, of course) as a bug.

You could try doing this via Ethernet instead of USB.  If it behaves differently then, that might suggest that bundling is being done for UDP-sized buffer sizes, but not quite making the translation to USB in some way.  I don't know.  I haven't seen the code recently.  It's just an idea.

I suspect that none of that actually helps you, but it might help somebody who has their head suitably embedded in that code to figure out what to look for.

I have sent the osc messages individually and it still has the same problem...I believe the pattern was always there, I just forgot to turn one of the digital outs off again and it locked it up..I am going to give the ethernet route a shot.  Thanks....I appreciate all your help. 

Chris