Driver code cleanup And Extend Drawing Range

[robbo1]

I have succeeded in engraving a picture on wood, but it requires an alternative way to connect the laser electronics to the controller. (one extra cable from the controller to an existing connector on the laser electronics board. Extra code in the driver is needed. At this stage the mods are not refined enough to release. To continue work for picture engraving I will need to duplicate the rig for testing purposes and honestly I don't have the funds/ability to do that, even though I wish to.

I am now updating the driver to have more efficient calculation of the angles and to determine the two possible angles for motor 1 and the corresponding angles for motor 2. This will open up 3 quadrants and some of the 4th for drawing if one wishes to mount scara in the middle of a board. But in any case it will open up all of quadrants 1 & 2 when mounted as per the instructions. Also arm 2 will be able to bend either side of arm 1. Also limits will be included to prevent the arms from contacting the mounting/frame.

It took a little time to ensure the maths was correct and that it would be possible to automatically choose which of the angles to use for motor 1. The new angle calc system plus existing code clean up is best done by a complete rewrite of those components in the driver.

I hope to provide a beta version of the code suitable for real life testing of the new calcs/stepping within 2 weeks. I hope some here will offer to test the new code when I put it up.

[robbo1]

I am currently testing my alpha version of he changes and it is looking good.

• limits on angles so no more crashing into the framework
• arm 2 can be on either side of arm 1 allowing greater range.
• the full quadrant 1 & 2 can be drawn on (excepting framework area obviously)
• if desired the limits can be set so that quadrants 3 & 4 can be drawn in if there is table exists for those areas

I expect that a beta version will be ready for testing by next weekend

[robbo1]

I have been tracking down an apparent positioning error noticed on drawing the impossible box where a redrawn line would appear as 2 lines becoming one. In tracking it down I ended up doing some good testing/debugging. The problem turned out to be a mechanical one where the belt from Motor B to Arm 2 was ever so slack allowing the arm some play and direction of movement affected actual position.

Also I have fixed up the speed control to use an acceleration table and also %speed actually does %speed/%acceleration. This means that if the "payload" is heavier resulting in greater inertia, both the acceleration and speed can be scaled back by simply changing the %speed to account for the greater inertia.

Also I have added by software resolution vs accuracy to the code which would allow the trading off of step rate verses accuracy. This is done without changing the hardware controller step rate. I plan on asking makeblock to add configuration for this too.

I am still playing with some factors and due to personal commitments it looks like next weekend before the beta will be uploaded.

[tipex20]

Thanks a lot robbo, you're the best !!

[robbo1]

Busy week. It is working except for coding to lift pen when it changes orientation. And some final acceleration tests to find suitable values. Also by rewriting speed control, the bug with Aux delays over 20mSecs has been fixed. Auduino has bugs for delays over 16mSecs using the delaymicroseconds() function.

I guess with another busy week it maybe a few days yet before i upload the beta for testing.

[robbo1]

I hope to upload the beta code tomorrow.

Have just done a large engraving of the car sitting across the 2 quadrants and compared to the example picture of the same car makeblock has on their forum site, the new code is a winner

Example picture of car sourced from makeblock site (forget where :( though). Notice that the different sections of the car do not line up, this is a result of code errors in the driver.

And this is a picture of the engraving I did just now. (sorry about the lighting, suggest clicking on it to view in full size)

my laser setting was not strong enough which you can see in the picture, but as you can see the accuracy is correct and engraved exactly what the mDraw program told it too. Enlarge the car in mDraw way past the drawing limits and you can see the finer detail of what will be drawn/engraved.

I sent the driver a series of random points covering the 4 quadrants and the code to prevent the arm from moving past set limits worked well.

[tipex20]

Wow, it's crazy !! It looks perfect ! I'm waiting for it to test it :) 👍

[robbo1]

I have uploaded the source in my fork.

Make sure you use the configuration in mDraw FIRST and click OK. That will cause the default settings for limits to be set and saved in EEPROM. If you don't then it will do silly things.

The source has explanations to the changes made in calculations and limits. There are limits on the angles the arms can move to and also an exclusion box that prevents the scara bot from attempting to move to a point which would cause the pen/laser to hit the framing.

To maintain accuracy, remember that the belts have to be tight (not over tight) so that there is no play in the arms. I was getting inaccuracies because I had not checked the belts prior to testing and the belt for arm two had a little play in it and caused lines to positioned incorrectly (1/2 mm). Tightened the belt and you can see the result for yourself.

Mind you the changes to the calcs and stepping method removed another form of inaccuracy that can be seen in the picture sourced from makeblock site.

EDIT: Link to source code https://github.com/robbo1/mDrawBot/tree/master/firmwares/scara

[tipex20]

It works !!! I will give you my feed back fast :)

[tipex20]

It seems to be a lot more accurate. It's impossible to do forbidden move now. Robbo1, you make this project a success !!!

[robbo1]

Now we need makeblock to do changes to config so as those limits can be configured and I just need to allow the drive to accept them from mDraw

Now I am trying to raise a little cash to buy another mDrawBot so I can continue development on the grayscale engraving. I need 2 to test things out. Oh well likely to be a future little project.

I made a simple change to the way my laser connects to the controller (controller sees no difference), but gives proper pwm control over brightness, rather than the incorrect method of using PWM on the laser's switching power controller input (within the black control box of the laser). When I do the grayscale project, I will change the control over to the 2nd servo control port to allow the controller to control the laser ON/OFF power and separate pwm input to control the power level.

That would provide correct driving of the laser ( == longer life for the laser) and greater protections, and allow people to put a separate switch which gives them an external laser enable safeguard. But I need a little money to do that. :(

[tipex20]

Have you got an email ?

[robbo1]

May I ask why? Do not like giving it out publicly though.

Obviously I have one :-)

[tipex20]

It's simple, I would like to give you 50 euros to help you a little by Paypal.

If everybody do the same, you will have enough very fast to do every test you need :) I think the BlockTeam should give you the same but everybody think differently.

We are lucky here to have you :-)

[robbo1]

ppp.rob at gmail dot com

I am sure you can work the addr out and it is a dot separating the 2 parts before the @. 50 euro will be a big help towards the "test bed" mdraw. I already have a second laser so only need to get the base unit. That saves approx 115USD

And thank you very much, the work may not be quick but it will be similar timeframe as I have been going.

[tonyballoni]

Hello all!

Its a very good improvment robbo1,I'm trying to port the Firmware to a more Powerful dsPic33FJ256GP710A Microcontroller,but I must see how to implement the micros() Function.
There is no such Instruction on Mikroc Compiler....

Regards

[robbo1]

Sorry without a sub milli second timer it will be difficult to get stepping accurate. Not familiar Mikroc Compiler. But the dspPic has more than enough capabilities to implement such a function. Its likely you will have to add a little C code or assembler to do this.

If you cannot then you could make one that is a dummy loop and calibrate it yourself to do the approx timing.

[tipex20]

Hi robbo1 :)
I hope you're fine,
Are you still there ?
Regards