Driver code cleanup And Extend Drawing Range about mdrawbot HOT 17 OPEN

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

from mdrawbot.

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.

from mdrawbot.

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

from mdrawbot.

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.

from mdrawbot.

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.

from mdrawbot.

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

from mdrawbot.

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

from mdrawbot.

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

from mdrawbot.

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

from mdrawbot.

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. :(

from mdrawbot.

Have you got an email ?

from mdrawbot.

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

Obviously I have one :-)

from mdrawbot.

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 :-)

from mdrawbot.

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.

from mdrawbot.

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

from mdrawbot.

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.

from mdrawbot.

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

from mdrawbot.