Hey Alex, great to hear of your build. Gaps are a bit weird. The position of each row is just calculated by multiplying the pixel size (or row size) - the two are linked. So if the row size is 100 steps, then each pixel is 100 steps wide, and each row is 100 steps away from the next. And when you change the row size, the row positions are recalculated. It's not impossible for the two to get out of sync, but I can't imagine where in the code it might have happened.

That said, if the square wave is not reaching the full width that's it should, it's more likely a physical problem where the pen tip drags behind the movement of the gondola. So the motors are probably moving the right distance, but when they change direction the pen tip doesn't follow the movement closely enough, and it ends up only drawing a zigzag down the centre of the pixel, rather than a neat square wave. If you see the pen tip staying still on the page while the motors are running, or the gondola pivoting on the pen tip, then that's the sign that it's happening.

It might help to see a pic of the output, if that doesn't ring true.

Hope that helps.
Sandy Noble

Hi Alex, thanks, do you mean the gaps between the lines in the main part of your photo? Those lines are empty pixels - the pixels you're drawing have zero density - they are empty, just a straight line. No square waves. There will always be empty spaces when there's no detail to fill it in.

I see in the very bottom corner there's something that looks a bit like a square wave, and it seems to be proportioned properly.

If you want your machine to express more detail, then you can increase the pixel size, reduce the pen size or use a darker image.

Hope that helps?
sn

Ha, yes, nice empty page! Yep there's enough contrast there in the source image, but the machine apparently disagrees.

Does your density preview (F2) show a full range of spots of different colours?

When you press "shade square" and the command queue gets filled with lots of C05 commands, they will all be for pixels of different brightnesses, the last number in each command signifies the brightness, on a scale between 0 (darkest) and 255 (lightest). Make sure that those commands that get generated are not all 255.

I think this might be a combination of pen size being not set, and using a pretty small pixel.

Try this:
Before you do the drawing, re-adjust the pen width using the keyboard ("[" and "]") just to make sure the values are being sent to the machine. I would also try a larger row size.

good luck!

oh, the time is probably ok - the image was empty, so no pixels waves were actually rendered, and that means it's fast! Because it's not actually drawing anything, it's just moving from one pixel position to the next. That's probably the first time the timer has ever been accurate 🙂 A4 is also not a big area - the ones that take hours and hours are A2, A1+ sheets.

sn

Not necessarily, the lines you see there mark the central axis of each row. If you have a large row size (big pixels) those lines would be far apart, if you have a small row size (as you have), they will be close. The distance between them is your row size.

Remember these lines you see there are empty - it is the deviations from this central line, the wiggles, that create an area of ink. If these lines are close together, then there'd be no room to create a range of densities.

sn

Aye looks like the code is OK - lots of different values.

So the controller portion is ok. I think you've got everything configured properly to be honest, and it's an issue with the pen size. Make sure you manually modify the pen size setting before you do your drawing (use "[" and "]") and give it a trial again.

Ok, have you tried a pen width test? Modify your properties file so that you've got

controller.testPenWidth.startSize=0.1
controller.testPenWidth.endSize=1.2
controller.testPenWidth.incrementSize=0.1

in it, then run the controller, and click "test pen widths", and it'll draw 11 pixels at your current row size, each one with a different pen width setting. It starts from wherever the gondola is already - doesn't need calibration.

At least some of the pixels should have some pattern.

Then double your row size, move the gondola down a bit and try it again.

This will confirm that it's working with at least some pen sizes, and pixel sizes.

sn

No that's not right at all, there should be 11 pixels (or 12, I can never remember if it's inclusive) - there's only 2 pixels there. Did you definitely replace the rows in the properties files with the ones I suggested?

I'm a bit stumped about that.

400 vs 800 steps per rev doesn't make any difference - like you've noticed, having 800 steps just makes for more resolution, and that's why it has the resolution to actually render some waves.

Let me have a think about it.
sn

It's a puzzler. What comes up in the console when you do the pen test width? On mine it does something like:

incoming: C11,125,0.1,1.2,0.1,END
incoming: Command:C11, p1:125, p2:0.1, p3:1.2, p4:0.1
incoming: Executing command.
incoming: MEMORY,637,END
incoming: rowsize in mm: 13.13, mmPerStep: 0.11, rowsize: 125
incoming: Max density: penSize: 0.10, rowSize: 125131
incoming: Penwidth test 1, pen width: 0.10, max density: 131
incoming: Basic seg length:0, basic seg remainder:125, remainder per seg0.95
incoming: First wave half
incoming: SYNC,6730,6070,END
incoming: MEMORY,556,END
incoming: SYNC,6731,6195,END
incoming: SYNC,6732,6070,END
...

and then a bunch of sync messages and then
incoming: rowsize in mm: 13.13, mmPerStep: 0.11, rowsize: 125
incoming: Max density: penSize: 0.20, rowSize: 12565
incoming: Penwidth test 2, pen width: 0.20, max density: 65
incoming: Basic seg length:1, basic seg remainder:60, remainder per seg0.92
incoming: SYNC,6856,6194,END
... etc

So the important row is
incoming: Penwidth test 2, pen width: 0.20, max density: 65
This says it's onto pixel 2 of the test, it's set pen width to 0.2, and with that pen, it's going to be able to squeeze in 65 waves.

There should be 12 blocks of these, each one with a load of SYNC messages. You can ignore the SYNCs, but I'd be interested in seeing the lines highlighted above.

sn

Alex, great, there is something funny: Processing is formatting the decimal number using commas rather than periods as a decimal separator.

That is, your command is
C11,40,0,1,1,2,0,1,END

Where it should be
C11,40,0.1,1.2,0.1,END

So it looks like a command with too many parameters - the board only looks at the first four commands - it thinks you've asked for a test pattern starting with a pen of size 0, finishing with pen size 1, and doing increments of 1 in between. Which makes sense, given what it's drawn. GOOD!

Whereabouts are you from Alex? I think it's a locale issue - your computer is configured to use a comma (,) as the decimal point when formatting numbers, whereas the board expects a period (.). 1,32 rather than 1.32. It's sloppy internationalisation on my part, but I know what to do to fix it. I'll give it a shot now and post back here when it's done. Shouldn't be long.

cheers!!
sandy noble

OK, have just committed a change to fix this localisation problem!

The new code is up at http://code.google.com/p/polargraph/source/browse/controller/trunk/polargraphcontroller.pde?spec=svn116&r=116 - give it a shot and let me know how you get on!

This will solve your original problem too I think. When you were saying to the machine "the pen is 0.4mm", it was just getting "the pen is 0". So that might explain why there was no detail!

SKILL!
Sandy Noble

Great stuff. I misunderstood how DecimalFormat worked! Sorted though, I'll make a note of this fix on the main page. Thanks for being patient - let me know how you get on with it!