When this happens to me, the gondola shoots off in the wrong direction, and judders around at top making awful noises, and it's generally because I've forgotten to set home.

If it works sometimes then I guess the configuration is loaded correctly, but you can check by looking at the console when the board resets, also the touchscreen shows the settings for a second too.

Is it only interactively when it happens, or only when working from SD?

If you run that little set of commands, does it ever do it?

cheers!
sn

OK, here is the file I'm using. It's a simple variable frequency drawing of a gameboy.

http://pastebin.com/xy11rECN

Here is the log from trying to run it. This is after a clean start:

http://pastebin.com/PiQS45WH

I start things up, turn on the motor, load the file, reload the file (because I accidentally erased a line in the queue), then start the queue going. When the board executes the first C05 is when the problem occurs. After that line finishes, it moves around as it normally would (assuming it was positioned correctly).

So I modified the firmware to re-enable the debug printouts on the C05 command, and produced this run:

http://pastebin.com/LiAymr24

The debug output lists sane points (1574,1184 and 1609, 1184).

But both runs show lines like "SYNC,196,148,END" right after that C5, which means the bot has it's position out of whack, right? That would explain why the motors both reel in so much if they think they have to take in more than 1000 steps.

My immediate programmer suspense is an overflow. I'm going to dig around and put/enable more debug code to try to figure out what's going on.

Thanks for that - very good stuff. I think it's heading up to a non-multiplied position. So it's going from your last good position:
C05,1591,1184,37,255,END

(which seems reasonable)
and next pops up, reporting that it's managed to make its way to SYNC,196,148,END

And I suppose its no mistake that 196,148 x 8 is 1568,1184 which is on the same row as the requested pixel. There's a value slipping through that's not being multiplier()'d.

Thanks for looking closer into this - I appreciate such good diagnostics!
***
after a quick look a the code, I guess this is because of the first couple of lines in the pixel file:

void pixel_drawSquarePixel()
{
long originA = asLong(inParam1);
long originB = asLong(inParam2);
int size = asInt(inParam3);
int density = asInt(inParam4);
...

All parameters coming in from outside are interpreted through the asLong(inParamX), asInt(inParamX) (etc) functions, and all native-coordinate instructions should also have multiplier(...) on them.

So those lines should be:
long originA = multiplier(asLong(inParam1));
long originB = multiplier(asLong(inParam2));

Pixel size should probably be multiplied too, though I think it's a matter of taste. I'm working myself up to metricking this size out to be an absolute value specified in mm (rather than steps), but that's for another day. For now it's steps:
int size = multiplier(asInt(inParam3));

But density is a number between 0-255, so no multiplying for it:
int density = asInt(inParam4); // same as it ever was

I'm not that surprised by this coming up actually, this is a fairly radical restructure of the codebase. I will have a closer look tomorrow.

Good night!
sandy noble

Checked out the latest version (r340), and it's fixed. The machine is successfully drawing, and didn't try to reel in a few extra feet of cord at the start.

Glad I could help. Splitting up the code makes perfect sense to me. It would have been large to begin with, but considering you have at least three different versions of the firmware to build I'm surprised you didn't do it earlier.

I'm going a little bonkers. I've tried using the latest bundle, and directly getting source for r340. My gondola is still shooting north at the first pixel, and roving commands never seem to happen. Since mbcook is having success, I'm wondering where I'm going wrong.
****STOP THE PRESSES****
I just tried uploading the r340 hex, and normal polargraph drawing now works. Roving stuff still isn't roving.

I've got it sussed. The filename of the image I was trying to render was toothless.pbm. Sending that filename resulted in a console message like "that file can't be found". I checked on the touchscreen, and the file was listed as tooth~2.pbm. I tried sending that as well, but it didn't work. I changed the filename to abc.pbm, and it worked fine. Typing the name abc closed the console, though - woops!
Short filenames FTW!

Yeah, I got it to work -- did a very nice norwegian render. And I figured out why my update didn't work until I used the hex (it was nothing you need to worry about).

I don't think I've used a pbm in twenty years...*oh god*...maybe more...I think a dial-up BBS was involved. I AM OLD.

Well, if it were a competition, I'd tell you I actually know the guy who made deluxe paint II, DOS, that's how old I am. Well, I've met him a few times, anyway. I was a game artist who worked with his wife back in the day.

Sorry. Back on topic from now on, I promise.