Sorry, I don't. I should have written it down before the update but I didn't.
If it helps, the printer was shipped to me on March 16, 2 weeks ago, and was assembled by your US partner fbrc8. Will you be able to find out from them what version they installed by using the serial number which I can provide?
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.
Same Problem here.
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.
Same problem here. Both of my UM3X machines. Started after the firmware update from 3.5 to 3.6.
@daid ;
send me a message if you need more info 
this is happening on all my printers after i switched to 3.6
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:
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.
- How often does it happen? Every print? Every day? Allways?
I'd say 95% of the time.
- What brand/size stick(s) are you using?
The flash drive that shipped with the printer, the Verbatim one.
- 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.
I did just find a fix to get around it. If the UM3 is not seeing the USB drive,If you go to change the material and then place the USB drive in the UM3 and go through the process of changing out material, once you go back to the main menu the UM3 will see the USB drive again.
A heads up to all of you, we think we have identified the cause of the problem and are working on a fix.
This still needs to be tested of course.
Thank you all for your patience!
A heads up to all of you, we think we have identified the cause of the problem and are working on a fix.
This still needs to be tested of course.
Thank you all for your patience!
Great news! Looking forward to it!
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.
8
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!
yes, the testing version is 3.6.3, and the only change that is made with respect to the current stable version (3.6.2) is this fix.
We have no reason to think the 3.6.3 isn't stable. It will most likely be pushed to stable on Monday or Tuesday when I have confirmation that the problem is really fixed.
We have no reason to think the 3.6.3 isn't stable. It will most likely be pushed to stable on Monday or Tuesday when I have confirmation that the problem is really fixed.
Perfect! Thank you very much for catching the problem!
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Daid 306
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)
Link to post
Share on other sites