Jump to content
Ultimaker Community of 3D Printing Experts
  • Sign Up

Daid

Ambassador
  • Content Count

    4,700
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by Daid

  1. I wish I could tell you "yes and a date". But that's not the case right now. In parts of the company there is still a heavy discussion going on on this topic. On all points (if, what, when, how, where). And the discussion is slow, due to it having low priority for most people that actually have a big say in this. Most of the printer logic itself is actually accessible already on the printer trough ssh, as it is python. So you could already patch that and send us fixes. Except for the display code, which is compiled C++, and to be honest, a mess. Combine that with the very few patches we got from the community for the Ultimaker 2, it's really hard to sell this. There is also a general difference in view on how certain parts should work. Engineers generally want more features, more options, more things to play with. However, a large part of our use base isn't engineers at all. So quite a few patches, while valid, we wouldn't merge, as they do not match our view (for the UM2, this is clear with the differences between the Tinker firmware and our firmware) Some parts are already open, like the kernel, u-boot, connman and a bunch of other things. Even the easter-egg code is published somewhere, if you know where to look (I got no pull request for that :( ). For Marlin, we have the issue that our repo has a lot of secret branches, and commit messages that referrer to secret things. But if anyone wants a copy of that source, we will share any release state. But we cannot open the repo till all those secret projects are purged or released.
  2. Oh, scrollwheel also works with this patch. As the rotation button already acts as a scrollwheel (for that I just had to fix the hot-pluggin)
  3. Just build the code to accept any USB mouse as alternative to the rotation wheel. The up/down movement of the mouse simulates rotating, the left button simulates clicking. Put it up to review for my fellow developers. With a bit of luck I will have a test version soon.
  4. Nobody has enough strength for that thing. I always stick a screwdriver under it to open it. Unless you are in a dusty environment, you don't need to do this very often. My Ultimaker Original ran for 2 years without re-lubricating. But results may vary. Not much I can do here to help however :( Hardest thing in 3D printing. Getting prints to stick to the bed while you can still take them off. But back on the main topic. I'll first put some effort in making sure a trackball works on the UM3. That should be relatively easy to implement.
  5. Never thought of it. That's a perfectly valid reason to improve on this situation! Is only better input handling enough?, or do you also need a better view of the screen? Is there any type of hardware input device that you might want to hook up to provide input instead? (USB joystick comes to mind) I don't know what your ideal situation would be for your specific situation. Better admit at being clueless then assuming the wrong things :-)
  6. If you just want the MAC address it is in the "System -> Network -> Connection status" menu. (It's shows the LAN or WiFi Mac address depending on the selection on the previous menu)
  7. We don't offer full remote control for a reason. As quite a few actions you need to be present at the machine to properly/safely operate. Most things you do want to do remotely, can be done with the API. (Just for reference. The rotation button is implemented a mouse wheel, with an "enter" keyboard button on a linux level. However, the display code ONLY opens hardware devices on startup, which is most likely why it's not picking up any other connected mouse) (I do have a python script that can be installed on the printer that allows full display control trough a web interface. Horrible hacked together piece of software, but occasionally useful for debugging at the office)
  8. The steps per mm on the X/Y for the UMO are not 80. But 78.7402, due to the MXL belts. See: https://github.com/Ultimaker/Marlin/blob/Marlin_v1/Marlin/Configuration.h#L458 (This is for the UMO. The UMO+ has a different Z steps per mm)
  9. It's bytes. And it's RAM, so runtime memory. GCode send trough network used to be in here, but now is stored on internal disk while printing with the introduction of Cura Connect. (Internal disk utilization isn't exposed on the API right now)
  10. Could be that the whole 5V power is dipping on a slight lose connection, which is causing the communication problems and the fan speed drop. Or could be that a communication error erroneously talks to the fan driver instead of the temperature sensor, momentarily adjusting the fan speed. In both cases, I would invest a tiny bit of time to seat the print head able better and putting some tape around it, as IRobertI also noted, this solves a whole bunch of issues. We've just pushed the fix to stable. (Together with language selection)
  11. Testing firmware should be quite stable, every printer in our office runs the testing version. Release shouldn't be far off. The 3.7 to 4.0 took long due to focus on other projects, and integration of Cura Connect. ER15 is almost certain related to the print head cable. Due to the cables not properly clamping in the top of the print head, cause communication to fail with the printhead. A quick fix is opening the top of the print head and putting some tape around the cable where it is clamped. So it's properly clamped, and no longer pulls on the connector itself. It gets worse over time due to the cable compressing on the only part where it is clamped. As you can imagine, this is quite a big problem for us, and we only just finished our investigation into this problem. Which I took part in, which is why I know so much about the cause. I don't know how support is handling the problem right now, due to that being out of my usual work area. We're also improving the cables, which where not exactly in specs, and the clamping, which could have been designed a bit better. To fully solve the ER15 issue. But that's all mechanical, in software we already did all we could.
  12. That's to be expected. We fixed the wrong temperature from effecting the control loop, but properly fixing the bad readings was more complex, so we decided to push out a simpler quick fix first while to better validate the full solution. The 2nd graph looks all like bed leveling. During leveling the heaters are off, as they are negatively effecting the bed leveling sensing.
  13. The odd 169 address is the address the printer will take if it never gets an address from the WiFi router. Can you check if your router has a feature called "band steering"? We've noticed that this feature in WiFi routers is causing problems for the WiFi in the Ultimaker3, depending on your WiFi router.
  14. I've been investigating most of yesterday and today. And I'm confident that I have a fix for the temperature fluctuations. The root cause is a single bad temperature sample is throwing the temperature PID controller in a bad state. Cause the heater to go full on/off for a few seconds. (Generally off) The bug is a combination of a bad temperature sample, the "functional range" logic and filtering on the "D state" of the PID controller. The reason we are suddenly seeing this now, is because of a different bug introduced. Which causes, occasionally, the temperature of the other hotend being read for a hotend. Which greatly increased the frequency of this problem. We where already testing a fix for this wrong-hotend-temperature problem, so we where aware of that problem, but didn't notice the large impact it had on the temperature stability.
  15. The tags only contain a material identifier, the actual data about the material is contained with the material database (in Cura and on the printer). So you cannot suddenly add ninjaflex without those being in the database.
  16. Someone just wanted to cut cake. But yes, this is for Cura 2.X, and it's actual users, not downloads. Tracked by the amount of update checks that our server is hit with from Cura. You generally have more downloads then actual users.
  17. Yes, the tags can be read and written. What do you want to achieve? We wanted to implement ndef records, but we made a mistake causing no other app to understand the data
  18. Note that this error happens if it takes more then 10 minutes to reach the target temperature of a hotend. When this happens, I'm interested in the following data: * Which material is being used to print? * How often does it happen? * The log files (from the diagnostics menu) as these should contain data about the heatup process. This will help in diagnosing if this is a software or hardware problem.
  19. What is displayed exactly? As displaying the "firmware code" wouldn't show anything readable. Most likely, you are hitting some kind of captive portal instead of our update servers. Meaning something else then our servers is answering to the update request. If you are in an office environment, you should ask for some assistance of your network administrator, could be a firewall that is causing your problems. (On our side, we should fix the code to not display whatever we get back from the server, but validate that it's a valid version number, as that is what it is trying to display. The response from http://software.ultimaker.com/jedi/releases/latest.version )
  20. We are only supporting ISO14443A. And the intent was for our tags to be NTAG compatible, however, we didn't implement that 100% correctly, so we are not. We are using the pn532 chip as our reader.
  21. Active leveling overrules your manual leveling. The reason for this is simple, the accuracy of the active leveling surpasses the accuracy of our experts at the office. If you want to use full manual data, you will have to set the active leveling to never.
  22. CORS with * disables all authentication, and thus breaks our authentication implementation. We could set it for pages that do not require authentication, but that gets a bit more complex pretty fast. However, maybe a better deal for all of us. We currently don't have a dashboard implementation scheduled yet. But I do want a landing page. So I wouldn't mind including your dashboard implementation in the next firmware release as just the default landing page.
  23. I said. Do not run the 3.6.90. There is nothing for you there, except for extra strange problems. The USB fix is in 3.6.3 on stable. (3.6.2 was the one with the USB problems)
  24. There is a firmware version 3.6.90 currently available as testing. However, this update has nothing of user value. We are currently testing a newer linux kernel (as the one we have has some nasty bugs) However, this new linux kernel exposes a old bug that has been popping up occasionally. But with a much higher frequency. The main problem is that your printer stops printing if this bug happens. We are currently using this testing version internally to diagnose the problem, but that means the testing version has stability problems.
  25. Nope. As the active leveling is searching for the point where the nozzle contacts the bed, without having expecting anything from the nozzle except for it existing physically, however, as we are not suppling this nozzle, no guarantees.
×
×
  • Create New...