Jump to content
Ultimaker Community of 3D Printing Experts
le_avion

UM3E sometime requires power cycling to see Flash Drive

Recommended Posts

I am on the latest firmware (3.6.2.20170322) and sometimes after plugging-in the USB Flash drive while the printer is on but idle and trying to print from it I either get a message asking me to plug the flash drive in or it tells me that the flash drive is empty. I need to recycle the printer's power for it to see the flash drive and the files on it.

Any idea?

BTW, how do you file a bug report with Ultimaker?

Share this post


Link to post
Share on other sites

Thanks for reporting this. We are currently aware of this problem. But we can use more information as we are currently in the dark for the root cause of this problem.

Do you know which version where you running before the 3.6 upgrade?

(For your information, I lead the firmware development team. So you have reached the proper channels)

Share this post


Link to post
Share on other sites

David, Im having the same problem as well. I got my printer like 2 weeks after launch and didnt touch the firmware after that so I had what ever came on the printer.

Ive tried a few things, it seems like after every print if I remove the USB drive and put it back in the UM3 will not see it. This goes for every drive I have tested so far. (5 to be exact) I have reformatted the drives as well and still have the same issue. Now one thing I did notice is I have a USB memory card ready, I placed a file on the SD card and placed the USB drive in the printer and the printer sees it, Now if I keep the drive plugged in but remove the SD card and go to a print a file the UM3 still shows all the files that were on the SD card even though its not plugged in. I dont believe the old firmware version did this. I dont know if that will help or not but figured I would mention it.

Share this post


Link to post
Share on other sites

I have been having this problem. Today, I accidentally clicked print on the Ultimaker 3 before plugging in the flash drive, and then I got a message saying something like "Insert flash drive". I inserted the flash drive and it was able to read the drive. This was the only time I was able to get the 3 to read the drive if I removed and reinserted it without a power cycle on FW 3.6. I have not had time to reproduce this, as it is currently printing, but I figured it was worth a shot for others who are having a similar issue.

Share this post


Link to post
Share on other sites

send me a message if you need more info :)this is happening on all my printers after i switched to 3.6

 

Not @daid here, but sitting next to him :)

A few questions:

 

  1. How often does it happen? Every print? Every day? Allways?

  2. What brand/size stick(s) are you using?

  3. If possible, check wat a dump logs to usb stick does. This 'forces' a remount of the stick and might even put the log files on the stick which we could use to find information. As @daid said in different topic, even after a reboot, you can do a dump usb logs which might help us pinpointing the problem

 

Share this post


Link to post
Share on other sites

It happens to me every time I unplug the USB drive.

I used the USB drive that came with my UM3, Sandisk 4GB,Sandisk 8GB,a USB memory card reader that had a old 256 MicroSD card,8GB and 16GB memory cards.

The dump Files wont write to the USB drives, It throws up some sort of error,If you power cycle the machine where it can see the USB drives it will write the dump files just fine.

Share this post


Link to post
Share on other sites

 

  1. How often does it happen? Every print? Every day? Allways?

    I'd say 95% of the time.

  2. What brand/size stick(s) are you using?

    The flash drive that shipped with the printer, the Verbatim one.

     

  3. If possible, check wat a dump logs to usb stick does. This 'forces' a remount of the stick and might even put the log files on the stick which we could use to find information. As @daid said in different topic, even after a reboot, you can do a dump usb logs which might help us pinpointing the problem

    SInce I am in the middle of a multi-day print I'll have to wait until it's done first.

 

 

Share this post


Link to post
Share on other sites

We think we have it!

While we are still testing to be a 100% sure internally. We've put this change up for installation already as the "Testing version" 3.6.3.

The only change in this update is the fix for the USB always showing empty file list issue. There is still a 2nd issue, where it shows a empty file list on the first try, and a full list if you press return and open it again. We didn't fix that issue yet (We do know the cause, but due to the easy workaround of closing and opening the menu we didn't spend time on that a fix yet)

The bug itself.

Now. If you want to get technical. The cause here is... the glowing of the LED ring at the front of the printer when your print is finished. What? Yes. This ring is glowing by some code on our side, but the LED output is controlled by a linux driver. So we are talking to this driver. Due to changes in how we manage the LEDs, we are updating this LED more times per second then before. A bug in the LED subsystem of linux caused every write we did to this LED ring to cause 3 or 6 "udev" events. This is a general event system from linux for hardware changes. Hardware changes that include USB removal or insertion.

Now, this LED glow was generating these events faster then they where handled. Creating a backlog. This backlog in turn caused the handler of these events to use a lot of system resources, at which point another system decides at some point that this handler is most likely misbehaving and needs to be restarted. Only increasing the amount work to be done instead of decreasing it.

Why is this important? Well, because these events where never proper handled anymore, the USB drive removal was never properly handled, and the insertion was also not properly handled anymore. Causing the system to look for the "old" insertion of the USB stick instead of the new one. And thus not being able to read it, it shows no files at all (and the read error never bubbles up to our code)

Currently we placed a tiny fix in the code to prevent these events, and nothing else. We already had plans to update our linux kernel towards a more stable version. But we didn't want to push out this kernel in a hurry just to fix this bug, at the risk of introducing a different (possibly larger) problem.

This was one of those, you have to be kidding me right? bugs.

Now, why didn't we catch this one during testing?

We didn't catch it at the development team because we clean our printers pretty much as soon as they are done. Our printers get updates multiple times a day, and you need a lengthy session for this bug to happen. Our testing team switched to mainly network printing to better validate the Cura network printing at the time this bug was introduced. So they did notice it once or twice, but didn't get to notice the severity of the problem. And they also had a bad batch of USB drives before, which made them a bit less alert on USB problems and quicker to think "oh, bad USB drive".

Why in the 3.6?

Wait you might say! The LED ring was glowing before as well. Yes. It was. But the update was at a lower frequency, reducing the amount of events, giving the system more time to handle them.

This change was introduced when cleaning up the LED control code during 3.6 development. Before this release the LED control code was pretty much the first prototype we made for this code. It functioned, but when we wanted to add the user configurable lighting, we also cleaned up this code. Introducing this unintentional bug in the process.

The big thank you

I want to thank you all for reporting this, and the people that helped in the diagnose both online and offline. It was a tough nut to crack, and really every tiny bit of information helped here.

  • Like 8

Share this post


Link to post
Share on other sites

We think we have it!

While we are still testing to be a 100% sure internally. We've put this change up for installation already as the "Testing version" 3.6.3.

The only change in this update is the fix for the USB always showing empty file list issue. There is still a 2nd issue, where it shows a empty file list on the first try, and a full list if you press return and open it again. We didn't fix that issue yet (We do know the cause, but due to the easy workaround of closing and opening the menu we didn't spend time on that a fix yet)

The bug itself.

Now. If you want to get technical. The cause here is... the glowing of the LED ring at the front of the printer when your print is finished. What? Yes. This ring is glowing by some code on our side, but the LED output is controlled by a linux driver. So we are talking to this driver. Due to changes in how we manage the LEDs, we are updating this LED more times per second then before. A bug in the LED subsystem of linux caused every write we did to this LED ring to cause 3 or 6 "udev" events. This is a general event system from linux for hardware changes. Hardware changes that include USB removal or insertion.

Now, this LED glow was generating these events faster then they where handled. Creating a backlog. This backlog in turn caused the handler of these events to use a lot of system resources, at which point another system decides at some point that this handler is most likely misbehaving and needs to be restarted. Only increasing the amount work to be done instead of decreasing it.

Why is this important? Well, because these events where never proper handled anymore, the USB drive removal was never properly handled, and the insertion was also not properly handled anymore. Causing the system to look for the "old" insertion of the USB stick instead of the new one. And thus not being able to read it, it shows no files at all (and the read error never bubbles up to our code)

Currently we placed a tiny fix in the code to prevent these events, and nothing else. We already had plans to update our linux kernel towards a more stable version. But we didn't want to push out this kernel in a hurry just to fix this bug, at the risk of introducing a different (possibly larger) problem.

This was one of those, you have to be kidding me right? bugs.

Now, why didn't we catch this one during testing?

We didn't catch it at the development team because we clean our printers pretty much as soon as they are done. Our printers get updates multiple times a day, and you need a lengthy session for this bug to happen. Our testing team switched to mainly network printing to better validate the Cura network printing at the time this bug was introduced. So they did notice it once or twice, but didn't get to notice the severity of the problem. And they also had a bad batch of USB drives before, which made them a bit less alert on USB problems and quicker to think "oh, bad USB drive".

Why in the 3.6?

Wait you might say! The LED ring was glowing before as well. Yes. It was. But the update was at a lower frequency, reducing the amount of events, giving the system more time to handle them.

This change was introduced when cleaning up the LED control code during 3.6 development. Before this release the LED control code was pretty much the first prototype we made for this code. It functioned, but when we wanted to add the user configurable lighting, we also cleaned up this code. Introducing this unintentional bug in the process.

The big thank you

I want to thank you all for reporting this, and the people that helped in the diagnose both online and offline. It was a tough nut to crack, and really every tiny bit of information helped here.

 

Glad to hear its been found. So is the testing version pretty stable then? Just contains the fixed code? Thanks!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Our picks

    • Introducing Ultimaker Cura 3.6 | Beta
      Ultimaker Cura 3.6 | Beta is available. It comes with new features, bug fixes, and UX improvements. We would really like to have your feedback on it to make our stable release as good as it can be. As always, you can download the beta for free from our website, for Windows, MacOS, and Linux.
      • 95 replies
    • Print Core CC | Red for Ruby
      Q: For some users, abrasive materials may be a new subject matter. Can you explain what it is that makes a material abrasive when you are not sure which print core to use?
      A: Materials which are hard in a solid piece (like metals, ceramics and carbon fibers) will generally also wear down the nozzle. In general one should assume...
      • 30 replies
    • "Back To The Future" using Generative Design & Investment Casting
      Designing for light-weight parts is becoming more important, and I’m a firm believer in the need to produce lighter weight, less over-engineered parts for the future. This is for sustainability reasons because we need to be using less raw materials and, in things like transportation, it impacts the energy usage of the product during it’s service life.
        • Thanks
        • Like
      • 12 replies
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!