search

texx00 / sandypi

The ultimate controller for sand tables
Other
28 stars 4 forks source link

Marlin 2.0.7.2 Serial Issues #30

Closed vincentbraillard closed 3 years ago

vincentbraillard commented 3 years ago

Hello Again.

I Have try a lot GRBL with my UNO but it's very random. sometime it go to the end and sometime no. So I decide to use a Marlin firmware with arduino Mega and Ramps 1.4.

But it's seem also to make some issues during the drawing. I hve try to lower the baud but nothing change. When I seen the manual tab, I see there is more and more lag on the serial scroll and sudently the motor is moving funny or stop..

Here is a txt log of the serial: MArlin Error.txt

When the motor stop, If I reconnect the serial, the motor start again

thank for your help

texx00 commented 3 years ago

Hi, I think that it would be better to increase the bandrate instead of reducing it. The problem usually is that the bytes sent keep the serial port busy when sending the next command... In my build I'm using 112500 baudrate and I have some small stops only when sending a lot of commands for small geometries with lots of points (like letters) but still the machine doesn't stop for more than half a second and it goes on again without problems...

I had a look at your log and it is surprising: I had that issue (#1) at the beginning but I thought I fixed it... Instead it is still there as I can see... Marlin is using a checksum and it's also numbering the commands so when something goes wrong it will ask back the line that had an error. I don't understand why when I send back a line like this the communication is messed up and it is not able to receive the resent line correctly and from there on it keeps resending wrong lines.

N3169 G1 X-100.987 Y-100.107 *52
N3170 G1 X-101.014 Y-100.134 *62
Line: 3165
N3173 G1 X-101.081 Y-100.200 *53
Error:Line Number is not Last Line Number+1, Last Line: 3165
Resend: 3166
N3174 G1 X-101.108 Y-100.227 *55
echo:Unknown command: "X-101.014 Y-100.134"
N3175 G1 X-101.128 Y-100.247 *50
echo:Unknown command: "0"
Error:Line Number is not Last Line Number+1, Last Line: 3166
Resend: 3167
echo:Unknown command: "4"
N3178 G1 X-101.202 Y-100.321 *53

Can you confirm me that before reaching that "resend : line number" it was working correctly?

The longer the file, the higher the probability of getting into this problem. In my cartesian build I run only short programs actually (they are smaller also because for a straight line you have only one command instead of multiple like in the scara case)

I will have a look for sure (I hope during the weekend). A quick fix may be to restart the lines numeration when facing this error but it may be a workaround more than a solution...

Still, this problem should not be related to grbl because there is not using line numbering... The problem there should be that during the drawing it misses a line and it create a wrong drawing... What kind of problems did you get there that made you try with Marlin?

I'm really sorry that you are facing all these errors but I'm doing my best... It's really that I don't get them... Usually I will consider me to be lucky if something works but in this case I prefer to have this kind of problems first to be able to fix them... 😞

Quick note: I merged the other changes on master... I don't know which version you are running now... If you want to run the latest use:

(env) $> git checkout master
(env) $> git pull
(env) $> sudo sh install.sh
vincentbraillard commented 3 years ago

Hello:

Concerning Marlin Yes, for sure, Cartesian table file are much shorter than thr....For exemple, the 2 following files are identical and are only 3time a square: Cartesian file: 54 line 3x_square.gcode.txt

thr file, 2001 line 3x_square.thr.txt

may be you could test a bigger file with your Cartesian table using a thr file modified with the small python file and modifying the step/mm parameter to fit you table size. so you could see the issue by yourself...

I have test with 115200 and 9600 baud and the drawing is stopping (stop and run every ~ 20ms) at the same level. when reconnecting the serial, it re synchronize again and restart.

Yes I confirm before the re sending, all goes well

Concerning GRBL

I Have decide to test merlin because you told me it was working better. With GRBL, the movement also stop and restart but the most problem come suddenly, a wrong value is sent to the motion board like you can see in the picture bellow and my scara come to hit the support!

20210207_092119

When Have you merge the with master? I have done the last install 2 days ago!

texx00 commented 3 years ago

may be you could test a bigger file with your Cartesian table using a thr file modified with the small python file and modifying the step/mm parameter to fit you table size. so you could see the issue by yourself..

That it's a good suggestion... I will try. Still, i'm thinking if maybe the scara conversion uses a too fine resolution... I mean, 54 vs 2000 lines looks like a huge difference... I don't remember the script by mind now but maybe we can check with different resolutions in the converter also (still the problem is due to a bug I need to fix, no doubt about that) to see what happens

(I merged the master 3 days ago so probably you are already there)

vincentbraillard commented 3 years ago

Hello. NO the length of the code doesn't come from the transformation script but is from the thr file for polar itself. The script just transform angle/lentgh to angle/angle for scara with the same number of line.

I normally use to test cncjs and all goes well with

texx00 commented 3 years ago

Hi, I just had a look and the bug was introduced with the grbl compatibility changes... I think I fixed it... I tried with a 15k lines file (only once really but my time is limited today) and it didn't show any problem. I also forced the lines to be missing and the controller is asking and receiving the missing lines correctly.

I introduced also a small change that may help with grbl increasing the reliability of the sent commands (but I'm not sure about this at all)

I found out that still sometimes at the end of a drawing the server get stuck, I will have a look at it later...

If you want to try it out you can:

(env) $> git pull
(env) $> git checkout fix_marlin_resend
(env) $> git pull
(env) $ sudo sh install.sh
(env) $ sudo python3 start.py

If this doesn't fix the problem let me know

texx00 commented 3 years ago

Update: I managed to fix also the problem about the drawing being finished but the sw was still waiting

texx00 commented 3 years ago

Update2: I did the tests with my laptop running windows and I didn't have any trouble with the fix. Now I'm trying with my raspi and it was not working anymore... I touched a value and now it is working again... I don't know what is going on... Let me know if it happens also to you...

texx00 commented 3 years ago

I shoul have fixed it now

vincentbraillard commented 3 years ago

Hello

So Concerning GRBL: It's seem I have no more stop now during drawing and it's much more stable. need more test to be sure but seem promising! But When I start a playlist of when I add some draw to the queue, the first draw finish well but the the second doesn't start! And when I try to stop the current drawing at this stage, the button doesn't seem to work. The only way is to stop the server and restart it.

Capture d'écran 2021-02-07 18:18:46

texx00 commented 3 years ago

But When I start a playlist of when I add some draw to the queue, the first draw finish well but the the second doesn't start! And when I try to stop the current drawing at this stage, the button doesn't seem to work. The only way is to stop the server and restart it.

Is it like this also if you wait for the first drawing to stop before adding the second to the queue?

I will be abroad for work this week thus I won't be able to do/test quick fixes... Still if you find out something wrong write it down

vincentbraillard commented 3 years ago

Concerning Marlin It's better in term of it doesn't stop anymore during drawing like before. need also more test to confirm I have started 2 draws with one in queue dans with marlin it's seem to work

I have try this draw who run well with GRBL. With Marlin I saw this error around line 62 63:

self.last_commanded_position.x = self.x_regex.findall(command)[0][0]

IndexError: list index out of range

FractalV10.85.gcode.txt

texx00 commented 3 years ago

IndexError: list index out of range

My fault... I will fix it as soon as I can. Still I think from what you told me this fixes are on the right way... I still have some more checks to the changes to do (for sure before merging) but I think it won't be before the next weekend

vincentbraillard commented 3 years ago

UPDATE

I Have restart the Raspberry and GRBL doesn't work anymore. Don't now if we need to restart it at each update butnow during a GRBL drawing, it stop. in manual windows there is no error and in the command windows I can see that when it stop!

ERROR:werkzeug:Error on request: Traceback (most recent call last): File "/usr/local/lib/python3.7/dist-packages/werkzeug/serving.py", line 323, in run_wsgi execute(self.server.app) File "/usr/local/lib/python3.7/dist-packages/werkzeug/serving.py", line 312, in execute application_iter = app(environ, start_response) File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2464, in call return self.wsgi_app(environ, start_response) File "/usr/local/lib/python3.7/dist-packages/flask_socketio/init.py", line 46, in call start_response) File "/usr/local/lib/python3.7/dist-packages/engineio/middleware.py", line 60, in call return self.engineio_app.handle_request(environ, start_response) File "/usr/local/lib/python3.7/dist-packages/socketio/server.py", line 560, in handle_request return self.eio.handle_request(environ, start_response) File "/usr/local/lib/python3.7/dist-packages/engineio/server.py", line 374, in handle_request socket = self._get_socket(sid) File "/usr/local/lib/python3.7/dist-packages/engineio/server.py", line 562, in _get_socket raise KeyError('Session is disconnected') KeyError: 'Session is disconnected' WARNING:engineio.server:Invalid session 38ba82e7151e4cdaa7e008cd6bb3a17e WARNING:engineio.server:Invalid session 38ba82e7151e4cdaa7e008cd6bb3a17e

PLEASE STILL DON'T MERGE

vincentbraillard commented 3 years ago

UPDATE 2

I have reinstall the master branch by doing:

(env) $> git checkout master (env) $> git pull (env) $> sudo sh install.sh

And now GRBL work again very good To be sincery with you, the only thing who doesn't work it's the end of the drawing. At the end, the "current drawing" stay and it's not possible to restart an other one. Else everything is working well in the master branch!!!

texx00 commented 3 years ago

I had a look and fixed both the stop problem with grbl and also the marlin issue (I hope).

I do not have the time to test it though... If you want and have time you can pull the fix_marlin_resend branch and try with that one.

If you get again the problem that the server is not running after a restart try to remove the file: server/saves/saved_settings.json and restart the server

To be sincery with you, the only thing who doesn't work it's the end of the drawing. At the end, the "current drawing" stay and it's not possible to restart an other one. Else everything is working well in the master branch!!!

I think there the problem was about some lines that (sometimes) were sent with wrong digits and the drawing was ruined. Still the new branch should work even better than the master for both firmwares.

No need to hurry with the tests, I will be away this week 😉 . I think I can bring the grbl arduino with me maybe to try something if necessary but not the marlin build

vincentbraillard commented 3 years ago

Hello

So My update. I will try to use same checkbox to compare version!

fix_marlin_resend branch: Marlin test

fix_marlin_resend branch: GRBL test

Master branch: GRBL test

texx00 commented 3 years ago

Hi, are you sure you are running the latest version of the fix_marlin_resend branch? Because in my (short) tests with marlin I have all the checks for the latest version there. And also with my hw-less grbl I can stop and start drawings...

You can check if you are running the latest version with:

$> git checkout fix_marlin_resend
$> git rev-parse --short fix_marlin_resend

The result should be 0dbc719 for the latest version. Maybe I released it after your tests

If it is not the same string use git pull and try again with the commands above to check if it worked.

Because otherwise I have no Idea what about what is going on...

vincentbraillard commented 3 years ago

I so:

Version is the good one: Marlin_resend_version

but under GRBL, the draw stop at the end but impossible to start a new one. only queue is possible! Can you share the file you did the test with so we are sure it's doesn't come from my file! I will check or change every component! With which grbl version have you done the test?

texx00 commented 3 years ago

I tested it with grbl 1.1 and the file you linked before here... The only thing is I shortened it... I do not remember if I tested the playlist actually... I tested the manual queuing for sure... I think I need to spend more time testing it on my own...

During a drawing need to wait a while to stop. Can you clear the buffer on click

No, this is something I cannot do... There is no command to clear the buffer on the device (that I'm aware of). The only way is to raise an emergency stop but in that case the board needs to be reset manually.

It is strange that marlin it's not smooth with the last commit... In my build is perfect... I tried 2/3 drawing (also the long one) and it is always smooth...

When I go back home I will make it draw the entire day to see what happens

vincentbraillard commented 3 years ago

Hello

So I have a goodnews. I was running on GRBL 0.9 (don't know why) and now I have made the update to 1.1h, it work very well!

Fix_marlin_resend branch: GRBL test

texx00 commented 3 years ago

Perfect! This is the news I was hoping for 😄

I need to check which marlin version I'm running in my build if you tell me that with the version of the title the software is not behaving as it is with grbl now. Also, when I have the time, I will try to load grbl 0.9 and check where is the compatibility issue with that one.

Still I will do more testing for sure also on my table to see if I was lucky or if it is really working for me with marlin.

I will merge the branch now anyway because it is for sure better than the master at this point.

I will also merge another branch I was working on. Unfortunately, this new branch requires to delete the settings that are already saved. Thus if you need/want to update the sw is better if you take a picture of your settings before pulling the update. No big changes here, just refactoring the settings page a little to accomodate for future updates. The page was too messy at this point.

Now I think I will focus a little bit more on the playlist if I have the time. I will add some timing options and other stuff.

Thanks for your help 😉