Ian Abbott wrote:
These are the files to reestablish control after disconnection of a browser.
It also duplicates status for a secondary browser. Let me know what you think.
how does it handle very large files?
David Lang
have you got a large file i can test with? I expect it would delay start up by the same amount of time as it took to load initially.
Bar,
I update the firmware. The wifi meter seems to be working. But now I’m stuck in extended state. Do I have to remove the bit and run calibration again after this update?
Thanks!
I started to recalibrate the machine and the wifi signal started dropping on me. The green button changed to yellow, and I was having control issues. It reported 100% packet loss, as it was receiving 0 of the 20 packets sent. Controls were very sluggish: When I would click to move the z axis so I could remove the bit it would be several seconds before it would move.
I
Maslow-serial 2-11 @809AM.log (6.3 KB)
FluidNC 2-11 @810 AM.txt (22.0 KB)
I eventually cycled the Maslow, restarted the wifi and my computer. Then I ran out of time for today .
The Maslow is extremely slow to move from the default Maslow network to the LAN. It does not even start blinking the blue light for at least 5 minutes after startup.
I will try again later in the day to reconnect.
Thank you,
1 Like
What does it say that your signal strength is when you are connected?
Awesome! I will give it a try!
Bar,
It gives me a 100% signal strength or a 0%. It transmits and receives all packets or none. There is no in between.
I tried to do a calibration on it because I still couldn’t start a job. When I tried to jog it gave the message the Maslow was not ready to move. During calibration It kept stopping for long enough that I thought it was complete and then it would start again. It was strange. It literally was calculating fitness on my screen and then it would move again.
Maslow-serial2-11 @ 1035 AM cal success.log (24.9 KB)
Maslow-serial 2-11 @1026AM cal failed.log (22.5 KB)
FluidNC 2-11 @ 1030 post calibration.txt (7.0 KB)
I tried a calibration, it failed. I tried again, it was successful but there was no message about saving the calibration. Those are the reports above. But I still had no control and couldn’t jog or load a gcode.
I reinstalled 1.17 firmware and index and ran a successful calibration the first try. No issues, no dropping, no sluggish movements that were delayed and sporadic.
Should I try the firmware and index files that ian_ab uploaded and then try this again? Will I need to calibrate it again if I do update the firmware and index again?
Thank you,
Once you have located your anchor points, you shouldn’t ever need to do it again unless their locations change. You should be able to extend the belts and then press “Apply Tension” to get them hooked up.
I think that figuring out what is happening with the wifi connection is really the first thing that needs to happen. As long as the wifi connection is intermittent it’s going to be impossible to know if a change led to an issue or if the wifi just happened to work one time and not another time.
Is there any other totally different location that you could try it out and see if it works differently in a different environment? No need to move the whole frame, just being able to see if you are able to extend and retract and stuff with no wifi issues somewhere else would be a valuable insight
I will take it home to test the wifi again. Should I use the firmware and index that you uploaded or the one that ian_ab uploaded later?
I reinstalled the original 1.17 and got it working. It is currently cutting a job. However I am now having problems with the sled lifting and rocking on the top edge again.
Thanks,
This is a test version and probably won’t help your problem. It is designed to reconnect after a WiFi failure and give you the controls back.
With the V1.17 at school did you have any trouble with browser dropping out?
You may be able to reduce the tipping by physically lowering the work area by 100mm or so, see the parameters for this in the maslow.yaml file to compensate if you try this. The problem with a vertical setup, as the belts approach a straight (TR TL) pull the forces required increase logarithmically and you also have to overcome gravity.
Increasing the angle from vertical can also help.
I will try the install the latest version that was posted last night later this evening. I’ll test it to see if it drops connection while retracting and extending.
For now, the job I tried to cut this afternoon failed because it disconnected from the computer. This was running on a LAN with no internet that was just set up in the room between the computer and the Maslow.
It couldn’t keep the sled on the board either. But I’m working on a solution for that. I would love to say it failed due to connection, but it just stopped from the connection. It wouldn’t really cut the board, The router tip was held way high because of the rocking of the sled.
Interestingly enough, the bottom right motor would not retract the line when I went to pack it up to take it all home. It took 2 extra clicks of retract all to get it to fully retract.
Maslow-serial 2-11 @305 PM.log (50.9 KB)
FluidNC 2-11 @ 320pm.txt (50.6 KB)
Again, any input would be very helpful.
Thank you.
This was not a network error.
from the USB log. the software crashed, which is what caused the disconnect (the possibility of this is why I push for logs via USB when people are having this sort of problem)
Guru Meditation Error: Core 1 panic'ed (InstrFetchProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x00000000 PS : 0x00060b30 A0 : 0x8201e7ea A1 : 0x3fcebfb0
A2 : 0x3fcafe84 A3 : 0x00000000 A4 : 0x00000000 A5 : 0x3fcf439c
A6 : 0x3fcf0c68 A7 : 0x00ffffff A8 : 0x8203e11d A9 : 0x3fcebf80
A10 : 0x3fcdb72c A11 : 0x00000000 A12 : 0x00000000 A13 : 0x3fcafd7c
A14 : 0x00000006 A15 : 0x3fcb0ff2 SAR : 0x0000000c EXCCAUSE: 0x00000014
EXCVADDR: 0x00000000 LBEG : 0x400570e8 LEND : 0x400570f3 LCOUNT : 0x00000000
Backtrace: 0xfffffffd:0x3fcebfb0 0x4201e7e7:0x3fcebfe0 0x42078655:0x3fcec030
However, there were problems before that that should have stopped the system.
These logs appeared in both files:
[MSG:WARN: Position error on Top Left axis exceeded 15mm while running. Error is -43.644mm Counter: 1]
[MSG:WARN: Previous error was -43.644mm]
[MSG:WARN: Position error on Bottom Left axis exceeded 15mm while running. Error is -53.445mm Counter: 1]
[MSG:WARN: Previous error was -53.445mm]
the system should have stopped at this point. It’s saying that the left hand belts are both about 2" different from what they should be.
what feed rate are you using? it could be that the machine is trying to move faster than it is able to. What direction was it trying to move and where on the workpiece was it? I would try slowing down the feed rate and see if you are then able to cut.
the logs below show that the machine was trying to pull really hard on both the top left and bottom right belts before it eventually did the emergency stop (before the firmware crashed) I don’t understand why it didn’t stop after the first set of errors.
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:DBG: Belt positions saved to NVS: TL=1029.27 TR=2412.83 BL=1362.72 BR=2586.86 state=7]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Top Left axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Top Left axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Top Left axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Top Left axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Top Left axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Top Left axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Top Left axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Top Left axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Top Left axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Motor current on Bottom Right axis exceeded threshold of 4000]
[MSG:WARN: Position error on Bottom Right axis exceeded 15mm while running. Error is 15.012mm Counter: 1]
[MSG:WARN: Previous error was 15.012mm]
[MSG:WARN: Position error on Bottom Right axis exceeded 15mm while running. Error is 15.015mm Counter: 2]
[MSG:WARN: Previous error was 15.015mm]
[MSG:WARN: Position error on Bottom Right axis exceeded 15mm while running. Error is 15.053mm Counter: 3]
[MSG:WARN: Previous error was 15.053mm]
[MSG:WARN: Position error on Bottom Right axis exceeded 15mm while running. Error is 15.078mm Counter: 4]
[MSG:WARN: Previous error was 15.078mm]
[MSG:WARN: Position error on Bottom Right axis exceeded 15mm while running. Error is 15.103mm Counter: 5]
[MSG:WARN: Previous error was 15.103mm]
[MSG:WARN: Position error on Bottom Right axis exceeded 15mm while running. Error is 15.074mm Counter: 6]
[MSG:WARN: Previous error was 15.074mm]
[MSG:ERR: Emergency stop! Stopping all motors]
[MSG:WARN: The machine will not respond until turned off and back on again]
[MSG:INFO: Reset during file job at line: 6115]
[MSG:ERR: Position error > 15mm while running. E-Stop triggered.]
Dlang,
I’m glad you can make sense of the report from the USB. I’ve kept it plugged in and recording every time I am using it so that I can get the most info possible.
The feed rate I was using was 40 in / min. That offhand seems high to me butt I read it on a spreadsheet of feeds and speeds. Do you have a recommended speed? I am about 20 degrees from vertical right now.
Thank you,
James Glaser wrote:
The feed rate I was using was 40 in / min. That offhand seems high to me butt
I read it on a spreadsheet of feeds and speeds. Do you have a recommended
speed? I am about 20 degrees from vertical right now. Thank you,
With the maslow, as a general rule, you want to move as fast as possible and
have the router spinniing as slow as possible.
but the key there is ‘as possible’, I would cut the feed rate in half and try
again to see if you get different results.
where on the sheet was it, and what direction was it trying to move when you get
in trouble?
David Lang
David,
It was in the upper right corner when it was rocking on the front of the sled.
I will reduce the speed back down and then slowly dial it up as it is successful. Yesterday when I had a successful cut I was using 20 in / min. Maybe I’ll try 21 in / min and see if that works.
Thank you,
James
Good evening all!
I was able to conduct a couple of tests on the firmware and index files that were published above. 117 A is the standard release of version 1.17. 117 B was from Bar in message 711 above, 117 C was attached above by ian_ab in message 719. Fluid NC was running with the usb connected the entire time. Each test I extended and retracted the belts 2x in my dining room.
Initially the Maslow would not connect to the wifi. It also kept dropping connection, but that was expected since that is what is has done historically on the Maslow network.
Maslow-serial Test 117 Startup.log (3.5 KB)
Once I got it attached to the LAN had no signal drop or any problems here. I changed from A to B to C with no incident. I was able to extend and retract belts with no problem.
Maslow-serial 2 Test 117A.log (4.3 KB)
FluidNC Test 117-A - C.txt (28.3 KB)
Maslow-serial Test 117 B.log (6.2 KB)
Maslow-serial Test 117 C.log (5.7 KB)
I plan to redo this test in the morning before I attempt to cut another test disk.
Thanks for taking the time to look over this and Thank you for any help you can provide.
1 Like
I suspect that the problems you are having connecting to the maslow network are your PC disconnecting you because it can’t get to the Internet.
in the log, we see
[MSG:DBG: /success.txt not found]
from a quick search I find
http://detectportal.firefox.com/success.txt should return ‘success’
that was not in my efforts to defeat captive portals in PR #277 but it looks like it doesn’t matter as @bar reverted that PR to try and solve some other problem and never added it back. Bar, I believe that we showed that this PR did not cause problems, but it’s a long time ago. I’m going to recreate it.
here is a build that should fix most of the captive portal issues and it also logs wifi client connects and disconnects. you won’t see the connect/disconnect in the browser that you connect with, but if you watch from another computer that’s not disconnecting via telnet or watch via USB, you will see messages like:
[MSG:DBG: WiFi event: 12]
[MSG:DBG: WiFi event: 14]
when a connect happens and
[MSG:DBG: WiFi event: 13]
when a disconnect happens (the client disconnecting the network, not a fade-out due to bad signal strength)
It also implements answers for something around 30 different captive portal protocols, which will prevent your computer from deciding that it doesn’t have Internet connectivity and disconnecting you because “you obviously don’t want to use a network that can’t talk to the Internet”
It will also eliminate the messages telling you to login to the network (and avoid starting up the limited captive portal browser to have you login). failure to login can also make your computer disconnect from the network.
It also generates logs of captive portal verification requests that look like
[MSG:DBG: Captive portal: 204 from 192.168.0.6]
and if there is a request for an unknown url (which could be a new captive portal request) you get a log like:
[MSG:DBG: URL not found: http://[unknown]/chrome-variations/seed - please report this to forums.maslowcnc.com]
(if you get lots of these and it’s still saying you need to login, it may be a new URL we need to add)
these logs are debug only, so they only show up if you change the log level from info to debug (left bubble on the fluidnc page) and we will probably want to reduce even these logs after we get some experience.
I’ve tested this with ubuntu/gnome, ubuntu/kde and android with firefox, chrome, and brave browsers (all of which do a test in addition to the OS test, and all test in slightly different ways not all of which are documented)
It would be good to get people to test from other operating systems
if you have been having disconnection problems, give this a try on the problem systems and see if it helps. It won’t help if the OS kicks into power saving mode and turns off the wifi, but should help if the problem is network connectivity (and the logging should help us confirm if it’s the client disconnecting or if it’s the maslow disconnecting the client etc)
firmware-package captive-portal.zip (1.3 MB)
David,
Thank you for looking into this and coming back with a solution so quickly.
I was starting to worry that to use the Maslow I would need to be able to have it connected to the internet, and that would not be an option for me. Each time i have tested it on a wifi network it has been disconnected from the internet. I do not believe I would be able to connect this to the general school wifi,
I will upload this firmware this morning when i get in and give it a shot.
Thank you again,
Good morning.
I tested 117 A - 117 D this morning.
All of those were successful in the test of retract, extend, apply tension, and then displaying ready to cut.
Maslow-serial Test 117C-2.log (5.5 KB)
Maslow-serial Test 117B-2.log (5.6 KB)
Maslow-serial Test 117A-2.log (5.5 KB)
Maslow-serial Test 117 D-2 Final.log (6.2 KB)
Maslow-serial Test 117 D -2.log (5.2 KB)
FluidNC Test 117 A - D 2.txt (59.9 KB)
I then went to cut a small test cut that is in the upper right corner again. The Maslow would not hold it’s position. I ended up releasing tension, applying tension, but it would not leave the extended state. The test cut was successful on Tuesday, has a 20 in / minute feed rate. It just would not draw it up.
Maslow-serial 2-12 @833 AM.log (8.6 KB)
Fluid NC 2-12 @ 833 AM.txt (10.2 KB)
I am wondering if the geometry of the board is going to prohibit use in the vertical orientation at the corners. Since the tension to hold it up increases so much as you get to the far sides, would there be a way to move the cutting area so that it is able to be reached? Or do I need to figure out a way to push the anchors out further horizontally? The original Maslow had a 10’ long header and the motors were mounted 1 foot from the edge of the board, but only 15 3/4 inches from the top of the cutting material. Now it is nearly 23 5/8. I am wondering if that steeper angle at the top gave more control. As far as force vectors are concerned this proposal doesn’t work because the flatter the angle (nor horizontal) the higher the the tension needs to be to support the same load. But what do you think?
Or should i just retract, extend, apply tension, so it is ready to cut and then prop it up so it is flatter. I’m not very comfortable with that solution, but if that gets the job done at this point I think I can live with it for now.
Thank you for your help,