Manual operation AOK Drawing operation stalls
- This topic is empty.
-
Posts
-
I have successfully uploaded the firmware to arduino, configured the ports and limits. Manual operation is working just fine, but every drawing I load starts and stops after a second or 2. I’m running Vista and arduino 1.0.5. Under arduino/libraries I have copied the firmware_ams1 folder, but placed AFMotorDrawbot as a separate folder under arduino/libraries. This is the only arrangement that the GUI software recognizes as functional.
Just after clicking the Draw/Start menu button, a window pops up with the message “set to 0 and click OK”. Is this a reminder to start from the Home position or something else I’m not getting?That’s a reminder to take the cap off the pen 🙂
What is the last message you get before it quits? Does the GUI say that the drawing is done, or does the robot simply… stop responding?
I have built a Makelangelo clone using info from your site and an arduino uno, adafruit v1 stepper shield, and adafruit 200 steps/rev motors. The steppers have their own 12v supply. I’m using Makelangeo software downloaded today from https://www.marginallyclever.com/other/Makelangelo.zip. I have edited the .ino file to define steps_per_rev as 200 and swap motor pins 1 and 2. The spools are 26mm in diameter, with a machine size of 700mm wide, 910mm high. Zero at machine center. Paper size of 630×630 mm.
The motors jog in the expected directions via the UI, successive jogs in the same direction do work.
The symptoms are:
Successive manual movements in the same direction only result in movement the first time. Changing direction will cause a movement “back”, but a second “back” causes no movement. This happens for both X and Y. The console window does show movement commands being delivered.Selecting a ngc file loads in the image window, “Draw” results in the “go to zero” message. “OK” causes the message to hide and one movement command appears in the console window. No drawing movements happen. I can pause/halt and get back to a responsive UI.
The console is reporting what seem to me to be unusual step_delay values in the hundreds of thousands or millions of (I assume) ms.
My pc is running win7 64 bit, starting Makelangelo wirh “start64.bat”, and ignoring the RXTX mismatch message.
Suggestions on where to poke the beast needed, thanks in advance.
It seems a few people are experiencing issues with the latest build. Thanks for spotting that step_delay thing, that’s a great hint for where the problem is coming from. I had time booked today to look into this issue so your timing is perfect.
I’ll post again when I find something.
Topics merged because they appear to be the same issue.
Ok, I think I found it. It was entirely my fault. 🙁
While trying to update the Arduino sketch to work more like the gcodecncdemo stuff I broke it in two exciting ways.
First, I was getting the feed rate all wrong. Basically a divide by zero. Whoops.
Second, G90, G91, G20, and G21 were all not working when they were on a line all alone. In a line with another G command they were fine. So relative moves with the driving windows was completely broken. Dang.
Both of these have been tested and appear to be working fine now. I’ve updated the download package on the website with the new firmware.
I’m sorry it took so long to get to this issue and relieved it’s working now.
Thanks for the quick update! Movements seem rational now. I am seeing random halts on large drawings, sometimes a “pause” then “unpause” lets drawing continue, other times the UI is frozen and unresponsive. I’m retrying the same ngc on a slower computer to see if there is a possible timing/handshake issue. The failure happens consistently about 4%-6% into the ngc running on the faster computer, currently at 14% into the ngc w/o halts on the slower and still running.
Not sure how to interpret the results, but a 1.4MB ngc file finished in 2 hours 20 minutes without any halts while running on an old HP laptop with 32bit win XP. The same ngc would not progress more than 6% without halt/lockup while running on a more modern laptop with 64 bit win 7. Makelangelo was started with the appropriate bat file in each case. The old machine is now relegated to Makelangelo use. 😀
People are certainly fascinated by Makelangelo, thanks for making it!
For reference, my “older” machine is an HP laptop, single Pentium 4, 2.8GHz, with 768MB RAM running 32 bit Win XP. My newer machine is a Lenovo laptop, dual core i5, 2.67GHZ, 4GB Ram running 64bit Win 7.
Does the GUI freeze (java error) or does the Arduino stop responding?
If the GUI has frozen the menus should no longer work.
On long prints with a 3d printer sometimes the serial connection drops out. Reconnecting resets the arduino. This may be happening to your machine. I’m told this is a problem with the way Arduino handles the USB connection and is a known issue with some models. I bet that’s why they changed their USB connection system in the Leonardo and did away with it completely in the Yun.
There seem to be two distinct “halting” modes. The most prevalent one is a halt in drawing which can be cured by a pause, un-pause via the GUI. In this case drawing continues but I think there may be a slight positioning error. The second case is a drawing halt with a completely unresponsive GUI, no response to the mouse/keyboard.
I’m still “solving” this by running on my XP machine and watching progress via TightVNC.
The pause/unpause sounds like the PC never receives the “>” character (queue ready to receive more)
The quit & restart sounds like dropped serial connection.
Both of these are reasons why I’m going to have an SD card reader in the next hardware update.
- You must be logged in to reply to this topic.
