jeffroe
-
Posts
41 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by jeffroe
-
-
It definitely seems like a design issue - it's obviously why they put that little bit of heat shrink on only one of the tabs. I would assume that without the protection diode chip the line would be broken if it was removed (if they are in series in the signal line).
-
Yeah - I am pretty confident that is what happened in my case - that tab shorted against that heater wire. I don't recall seeing obvious visible damage to either U3 or U8 on our board, but replacing the board with a spare solved it.
I wish we could have tracked down that digikey shipment to try to "save" that bad board, but been too busy to bother ordering more of them. I think we probably still have the bad one in a box or drawer somewhere if I ever get motivated to try to desolder and replace the two components.
-
13 hours ago, Whom said:
I have been trouble shooting the same problem and found that the U8 chip has clearly let out the magic smoke on our machine. See attached photo.
I presume it was caused by the same issue, but haven't noticed worn through wiring on any of our core heaters. I'll check again.
Seems like, from the inclusion of that little bit of heat shrink, this was a design error on the machine.
I ordered those protection diodes and the cap sense chip from Digikey back around the time I posted my saga with the intent of trying to replace those chips on the board I pulled out of that extruder.
Unfortunately during the working from home and COVID situation, the shipment got lost in the building after it was delivered and I never bothered to order another set.
-
Is there any reason this can't be run on a Raspberry Pi 3 with a decent sized SD card installed?
Also, it is something that can be left running all the time, so it creates a new video file every time the printer runs a job (perhaps incrementing the name by one digit)? Or does it need to be run manually before you start every print job?
-
1 hour ago, Torgeir said:
Hi Jeff,
I've been looking into the wiring diagram for this circuit and since this heater element is driven by a NMOS p-ch transistor,
both of this wires will be positive when no power is feed to the heat element. When the transistor is switched to on (for heating), the defined negative pin goes to ground. This will continue in a cycle pattern according to heat demand. I'll think ultimaker is using the "bang - bang" mode with a fixed frequency and timed on/off cycle (for reducing EMF noise).
Anyway, it looks like your "capacitive electronic chip" is most likely fried by the 24 VDC. Max input here is +3.3VDC!
Way to go.. 🙂
Thanks
Torgeir
Thanks for your help on this - much appreciated!
Which chip is this on the board? Is it commonly available? I would like to replace it on the board I pulled out if possible.
-
1 hour ago, Torgeir said:
Hi Jeff,
great to hear that this printer is up running again.
Way to go.
Torgeir
Thanks - I took some pics of the wire under a cheap USB microscope. Definitely a break in the insulation on one of the two wires. I checked with a meter for continuity to the terminals on the back of the print core and the wire with the break was connected to the 2nd connector on the back of the core (viewed from the back). I dind't check which pad this mapped to on the back - just the wire. I would be curious to know if that is a +24V line or ground.
-
1
-
-
On 3/3/2021 at 7:44 PM, Torgeir said:
This is a more close up pictures for sure, -but cannot be sure that there is an open wiring.
At this close distance from the heater core, the heat will extend along the wire and sometimes you burn the insulation at some distance from the sleeve. But with this much wear and tear on the fastening tab, it's strange if there is no hole in the wires insulation..
Another thing, if there is no short here, this short/close distance -mean higher capacitance.
So could this increased capacitance be the reason for (out of specification sensed) this error?
For sure, there is some options.
We'll se tomorrow.
Thanks
Torgeir
Just finished making two changes...
- Added a bit of solder to the front of the connectors that hold the wires to the cap sensor board in the steel plate. There may have been a small crack in the solder, but I think it was just a shadow in my photos.
- Replaced the PCBA in the extruder head
It successfully passed the active level sensor test (no more low performance error), so I am now running the XY calibration print it has been unable to do since this issue started. After this print I am going to take another look at the wire on the print core I removed yesterday and try to get a better photo.
since I changed two things at once I can’t be 100% sure the PCBA in the back of the head was bad, but I think it is likely.
-
We have a "spare" print head PCB here from one that had a massive blob of material after a mechanical failure (head assembly replaced under warranty). If i get time soon I will try swapping that out.
-
25 minutes ago, Torgeir said:
Hi @jeffroe,
Good catch.
It looks like it is burned, -should not be as the place it is touching is "cold"..
If you look more closely, could there be a hole in the insulation?
This is the heater, and if this is the +24 VDC this can make some heat.
So if 24 VDC enter this "ground" that's alternating at a frequency, the capacitive sensor might be destroyed.
This one is actually installed inside the print head, the mall PCB where the fan and the capacitive sensor connectors are installed.
Again check this little brown spot and if you see the wires in there, -you know whats failed..
Thanks
Torgeir
I will take a closer look next time i am in office. I wondered the same - it could be a hole in the insulation or at least a place where it frayed (since the heatshrink on the tab was in bad shape I think this is a good possibility. Here are a few more pics I took this afternoon along with a pic I think I posted before of the tab on that side of the sensor board. I put new heatshrink on that tab now.
-
Update to my issues:
I replaced the heatshrink on the RH tab that was deteriorated and reinstalled the bottom cover with no change in the leveling test.
I then tried pushing the heater wires up to make sure they weren't in contact with the tab. No change.
I then replaced the RH print core with a different one. There was a noticeable mark on one of the wires (see pic). Still no change.
Removed both print cores and tried to do the leveling sensor diagnostic. Test wouldn't complete so I backed out.
Factory reset printer. This DID change something. It would at least go through the entire process of the test, and then popped an error about low performance of the sensor. I made sure that the wires were separated well (front fan and sensor wires), and confirmed that the wires were all intact and not loose. Still the same low performance error.
Tried running the XY calibration and it errors out saying that it couldn't complete. Note this is different error than i was getting before the factory reset. The older error would be a white screen with black text that you can't exit from without power cycling the printer. The new error can be exited out of and I can get back to the menus.
We have a new bottom cover/sensor assembly on order. Hoping that fixes it, but I just don't know.
Note that the picture attached shows the print core that was in the printer initially in the RH location on the right of this photo. The one I put in its place is shown on the left. You can see a dark spot on the print core heater wire (or is it the temp sensor wire?) in the photo.
-
Update: ONLY the LH core was swapped - not the right. So I guess that is something else I need to try next week!
Thanks again
-
2 minutes ago, fbrc8-erin said:
The reason the heat shrink is there is to protect the heater cable for Print Core 2 so the metal tab doesn't damage it when the print core is moving up and down.
It's not needed on the other side because that Print Core is static and doesn't move up and down.Is your Print Core heater cable damaged by any chance? Have you tried swapping the Print Cores from your other machine in?
We did try different print cores and that didn't help (I know they swapped the left core - i am waiting for confirmation that they also swapped the right). I will inspect those wires more closely next week.
22 minutes ago, Torgeir said:This last picture makes me wonder, could this heat shrink tube be used as an insulator, in order to avoid any short short between the heat block (no 2 - the right) and the shield...
It might be the heat block that's made this damage to the shrink tube.
This ruin the measuring.. The right nozzle go far down in the housing and this must be the real reason for this tube/insulation damage...
Maybe a new lesson for us, -and sure me..
I'm curious to see if this is the cause of your problem..
Awaiting..
Torgeir
I will go back in next week (I am off work for a few days now) and inspect further to see if I can see if that was being rubbed/damaged by something in the head. I didn't probe them myself, but someone else confirmed no continuity between the metal bottom plate and the nozzle. I will double check this too while I am there.
So the print bed moving toward the sensor is what the sensor is detecting? I was guessing that it was detecting a change in capacitance as the RH print core touches the bed and the brass block moves upward and away from the steel plate in the head.
Thanks for the feedback!
-
38 minutes ago, Torgeir said:
Hmm. Strange this..
Both side of the cap sensor attachment holes is shield connected.
In the first posting, you've mention there there seems to be a sign of "corrosion".
The contact point of the red wire is isolated from the shield, and it is passed through the PCB connection to the "active" sensor foil on the underside of this circuit board.
The two picture of the sensor is made before and after cleaning and I guess the sensor was removed for this issue.
Maybe worth mention, cleaning captive sensors with water is a no, no thing in general.
However, since you mentioned corrosion, could water (due to high humidity "storing")been entering the PCB infill?
In general, -very rare, -but possible.
Water in one of the worst thing to fight in any capacitive measuring system.
As the nozzle is true ground and the shield is not -there should be no electrical contact between them.
When the metering procedure is ongoing, the slow speed approaching bed toward the nozzle will meet and the "capacitance increase" stop changing, -this is the signal to the software to stop moving the bed.
When measuring this sensor for open circuit and more than 100 M ohm resistance (reading OL - open line) is good.
From the red connector point to the underside "PCB" foil, we should red ~0 Ohm resistance..
That's pretty much all you can do, -before sending the printer to repair..
Last thing, or "sometime" first thing to do, -is to try "reset all printer setting" -will not erase the print cores data..
Maybe someone else have something to add..
Good luck
Thanks
Torgeir
I just got back from the office and read your response. Thanks for that!
The two photos show 2 different printers. The one with the "clean" RH tab holding the PCB in place is from the working printer. The other photo shows the sensor board on the printer that keeps throwing the error, and has the RH holding tab showing what I previously described as corrosion (before having the opportunity to see it firsthand this morning).
After seeing it this morning - I think it might just be that that "insulating" sleeve is deteriorated (almost looks like it is shredded). I am attaching another picture of it.
I ended up removing the bottom plate assembly and bringing it home with me, along with another bottom plate/sensor board that we had from a print head disaster about 9 months ago. That failure resulted in getting a new extruder head assembly, but we kept the old parts "just in case" we needed them. This spare plate is not in great shape (bent) because the entire extruder filled with melted plastic.
I may attempt surgery on the two - or just try to fit new wires/connectors to the spare and bend it back into shape.
-
17 hours ago, Torgeir said:
Hi @jeffroe,
Did you really unplug the cooling fan and test? This is a must to do as the fan might create to much noise, even if the cables are located in the right place when fan is running.. This is something @fbrc8-erin learned us sometime ago.
When the leveling process start, the program read the "capacity plus stray capacity" in the head. As long this capacity is within specs, the bed start ricing. At certain height the program expect to see that the capacity is increasing, but if this is not happen, the bed go to home position the process is aborted and signal an error.
Also, the inside shielding of fan and lo part of housing is part of the active capacitor (shield side).
This little "heat shrink tube" might be a "rubber spring", -placed there to prevent the capacitor plate to vibrate and give false reading. (Just needed on one side.)
There is a weak point in the cabling (all moving cables has a lifetime) and this point is where the cables is bent when opening/closing the core/fan cooling door.
There can be an open wire, either the red or the withe but this will not be detected by the system cause it still can read a capacitance as the ruptured parts is close together (because here is an A/C present with a frequency that's measuring the capacity of the setup).
So, there might be a rupture inside the insulation that you cannot see.
Thanks
Torgeir
Yes fan disconnected at the back, and it still errors out.
I just reinstalled the silicone boot and tried with the fan plugged in again - still errors out.
Also checked continuity from the board terminals to the connector on the back of the extruder - those look fine. Tugged on the wires at the board, they seem solid.
So basically stumped here.
-
12 minutes ago, Smithy said:
I've wondered the same thing, it's the same with mine and also with the S3. I think that is also not electrical insulation, that would not make sense.
Have you tried to raise or lower the bed a little bit, this often helps in such cases.
I am heading to the office tomorrow to investigate further. I don't think raising or lowering the bed will help here, since the bed only gets halfway up to the nozzle (from the bottom location) before the error comes up. At least this is how it was described to me - so I will confirm tomorrow.
My assumption is that those bent tabs are an interference fit into the holes so there is electrical contact between the steel plate and the plating on the inside of the PCBA holes, and they are then bent over (and outward) to mechanically hold the plate in place. I think the plate needs to be electrically connected to those holes for proper operation. And whether that is an insulative part is confusing. My thought is that maybe there is a vulnerable trace on the right edge of the board that they are making sure doesn't get shorted to the steel tab during manufacturing - but this is pure speculation.
-
Also, why is there only an insulator placed on that right-hand hole?
-
I know this is an older thread, but is it possible to elaborate on the way that this sensor works to help with troubleshooting? One of our 6 printers is doing exactly this, and we checked the fan cables and other cables - all look OK. There are no sources of interference nearby either.
The capacitive board appears to be electrically connected to the steel bottom plate (the "shield"). Is the steel plate supposed to contact the brass extruder body? Or is there supposed to be a nominal gap there? When the nozzle touches the bed, I am assuming that the brass moves away from the steel plate causing a change in capacitance?
It just seems odd that the process fails before the bed even gets up to the nozzle. This would seem to indicate that the sensor reading is out of range for the "nominal" condition of the extruder (when no bed contact is occurring).
We did notice that the right-side hole of the sensor board looks a bit "off" compared to the other printers we have (sort of looks corroded - or "fuzzy"). I attached pics of the "problem" printer board and the "good" printer board. It appears to me that there is an insulator wrapped around that mounting tab on the right side and the insulator has deteriorated or something. (Someone else took these pics so I wasn't there to see them in person).
Thoughts?
-
We have 6 of the Ultimaker S5 printers installed at work, and one of them has experienced the failure shown in the attached pic.
The first time we were able to remove the large blob of material from the extruder and reassembled everything, but it happened again a few days later. We ran a short test print (or two) to confirm it was running correctly after the first reassembly.
A similar incident occurred on another one of the machines shortly after we deployed them. That one had a massive blob on the extruder and we ended up getting that extruder replaced under warranty. (The blob couldn't be removed).
Does anyone know what may be happening here? It was running unattended, so we don't know what caused the issue. Maybe the part(s) came off the bed and caught on the extruder? Is this a common failure mode with these machines? They are just over a year old now (maybe 14-15 months?). The material in this print was Matterhackers Blue PLA, which we have run successfully through these printers (at least 10 spools worth).
I am assuming that there is no way to record timelapse video from the webcam (like Octoprint can)? Thinking about setting up a camera feed separately to see if we can see what is causing this.
Thanks!
-
4 hours ago, ctbeke said:
Hi,
Great to see that you were able to set up at least 1 printer!
First of all, could you send me some logs for the printer that didn't connect? I'd like to see what's going on behind the scenes there to see if it's something we didn't know about yet. You can dump the logs to USB from the settings menu and then upload them here or send them to me in a private message.
I may not have been clear in my last post. I actually WAS able to get the problematic printer connected. When the first printer was having issues, I tried a different printer and it connected with no problem. So I then went back to first printer, did the "Reset Digital Factory" option in the Network Menu, and attempted to connect it again, and was then successful. So I do have both of them connected. If we choose to go down this path, I will probably go ahead and do a Digital Factory Reset on the remaining 4 printers before attempting to connect them. I am not in the office today, but may have to go back in in the next day or two to pick up some parts I forgot to bring home with me. I don't know if it is worth pulling the logs, since we were able to get them connected after all. If you think there is still value in that, I can do it when I head back in...
Does this Digital Factory Reset basically clear all groupings of printers locally too? As I read your previous responses, these printers will still be available locally, and are still subject to the possibilty that other users may inadvertently re-group them locally, correct? The only way to prevent that would be to do a firmware update to the 6.x firmware and enabling the firewall to shut down local access ,nd that firewall is OPTIONAL in firmware 6.x? (We haven't done the 6.x firmware update on any of our printers yet.)
QuoteAs for your questions:
1) That really depends on the customer. We usually see that one person 'owns' the printers and they add the printers to their account and share it with colleagues in the Digital Factory. But we've also seen that printers are added by multiple people and all shared in a team. I guess it's mostly about who do you see as the administrator of your printers.
OK - that makes sense. A cloud printer can be added by more than one user, but it would be better to have one user add all the printers and then share those printers with the other users? And more advanced user management is available for the Essentials/Enterprise product?
Quote2) The camera already works via the cloud. It shows an updated snapshot every 10 seconds in order to reduce bandwidth needed and improve performance (the printer is spending most of it's valuable CPU time actually sending G-code commands to the controller). Do you get another result?
I just double-checked the camera feed remotely for the two cloud printers we set up while NOT connected to our VPN, and you are correct -- the camera feed is visible at the 10s update rate. So you are correct - it is working after all.
QuoteChris
Thanks!
-
3 hours ago, jeffroe said:
One more question for you Chris...
I am in the office and thought I would try connecting one of the machines to the Digital Factory. However, it doesn't seem to do anything when I pick the "Digital Factory" menu item and enter the code I get from the Connect button press. No printers show up in my digital factory. The button on the Digital Factory page shows "Disconnect" after I close the window with the code. I have tried a few times with no luck.
Does the firmware NEED to be at the 6.x level for this to work? We are on 5.8.2.0
Replying to my own comment. I ended up trying another printer (right next to the one that was having issues), and that one connected just fine. I went into network settings and reset the Digital Factory settings, and after that I was able to add that printer to my cloud account as well.
So now that I have seen that in action, more questions!
1. What is the typical setup for a large group of people? Should one person add all the printers to their account, and then create a team (or teams) to share those printers with? And these are all treated as individual shared printers then (not groups)?
2. Is there a fix in the works for viewing the camera feed for a cloud printer?
Thanks again!
-
One more question for you Chris...
I am in the office and thought I would try connecting one of the machines to the Digital Factory. However, it doesn't seem to do anything when I pick the "Digital Factory" menu item and enter the code I get from the Connect button press. No printers show up in my digital factory. The button on the Digital Factory page shows "Disconnect" after I close the window with the code. I have tried a few times with no luck.
Does the firmware NEED to be at the 6.x level for this to work? We are on 5.8.2.0
-
12 hours ago, ctbeke said:
Hi,
Here's some answers to your questions:
- How are these printers getting grouped in the first place? I suspect that the users who aren't as familiar with the system as I am (and others in the team that helped to deploy them are), and they are blindly clicking a prompt that is suggesting a group, but I can't be sure because I haven't seen the prompt myself.
Printers will certainly not group by themselves, so very likely someone else in the same network has done that.
- Can grouping of printers be prevented?
We have released Firmware 6.x for the S3 and S5, which allows you to enable a firewall which blocks all local network access to the printer (and by doing so blocking the ability to group printers). You'll have to use the cloud-based Digital Factory or USB to print if the firewall is enabled.
- Is this grouping method even useful when the printers all have different materials loaded? Some may have Ultimaker filament loaded, others are using generic PLA, etc. My understanding of this grouping process is that you send a print to the host, and it relays it to another printer in the group if it is busy. Is this correct? How are materials managed then? Normally, I would connect to a printer with Cura, use the dropdown to determine which material is loaded in it, and then I print with that material in mind...
Grouping is mostly useful if you want to treat all of your printers a just a single production unit, not caring about which print job ends up at which printer. If you use different materials in each printer, it might be easier to have them all separate indeed and just select the correct one in Cura on the top left when slicing.
- Are these printer groups really part of the "Digital Factory", or is this more of a subset of that (since I don't believe that we have created any teams with printers associated to them)?
Originally printer grouping was part of "Cura Connect", then became "Ultimaker Connect", and now is part of "Ultimaker Digital Factory". However the grouping still runs in the local network, and the cloud functionality is built on top of that. I personally prefer not to use the grouping (as it can cause other issues due to the wide variety of local network configurations out there) and just connect every printer by itself to the cloud, and then sign into Cura and automatically access all the printers.
Chris
Thanks Chris, some of that is helpful, but you prompted a few more questions...
1. Can you tell me what circumstance might be creating a pop-up notification that might prompt a user to group a printer? I would like to recreate this and screen shot it with some instructions for the users on how to proceed in those cases.
2. If the printers are connected via the cloud does this pose any network security risks? I would like to inquire with our IT department about this and see if they have any concerns. Can you provide a link to some documentation that explains how this works (user management, etc)? Does this require an Essentials subscription?
3. Is the pricing shown on your web site for the Essentials subscription a per company cost, or a per user cost?
4. With the cloud option, I assume that we wouldn't need to VPN into our corporate network to access the printers anymore? Anyone with an account and permission to access them would be able to see them (this probably falls under #2 above).
I will do some more looking on your site for more details on the Cloud factory option, but I am signing off here from work now. 🙂
Thanks again!
-
Hello,
I am not sure if this is a topic that would fall under this digital factory topic (since as far as I know, we don't have one created), but I had to ask some questions and this seemed like a good place to start.
We have six of the S5 printers deployed around our building, and our INTENT was for them to all be individually accessible via Cura for our engineers. Unfortunately, we have been running into issues where printers are getting (inadvertently) grouped together, and this makes them inaccessible via Cura (a message pops up in Cura saying that the printer can't be connected to because it is not the group host). It appears that this grouping can be un-done, but it requires a confirmation button press on the printer in question (or maybe the host printer). This wouldn't be a huge deal, other than needed to trek across the building to push said button. With remote work now, this would now require a drive from our work-at-home office to the actual office to accomplish this.
So I have a couple of questions:
- How are these printers getting grouped in the first place? I suspect that the users who aren't as familiar with the system as I am (and others in the team that helped to deploy them are), and they are blindly clicking a prompt that is suggesting a group, but I can't be sure because I haven't seen the prompt myself.
- Can grouping of printers be prevented?
- Is this grouping method even useful when the printers all have different materials loaded? Some may have Ultimaker filament loaded, others are using generic PLA, etc. My understanding of this grouping process is that you send a print to the host, and it relays it to another printer in the group if it is busy. Is this correct? How are materials managed then? Normally, I would connect to a printer with Cura, use the dropdown to determine which material is loaded in it, and then I print with that material in mind...
- Are these printer groups really part of the "Digital Factory", or is this more of a subset of that (since I don't believe that we have created any teams with printers associated to them)?
-
Hello,
I am not sure if this is a proper place to ask this question, but does the Ultimaker Essentials (Enterprise) allow one to configure things to PREVENT users from grouping printers together? We have six S5 printers deployed around our building, and struggle quite freqently with getting unwanted groups created. See attachment. We probably have 50-ish users that are using them, and I think some of them blindly click prompts when they shouldn't. Since we are mostly working remotely, it is a pain to have to go into the office to confirm removal of a printer from a group (which seems to be the only way to remove them).
Constant notifications on printers with confirmation code
in UltiMaker 3D printers
Posted
We have a fleet of 6 UMS5 machines deployed in our office, and recently we started getting very frequent notifications appearing on the screensstating:
"To confirm the connection with this printer, use code: 123456"
We have a lot of Cura users scattered around our building, so my assumption is that someone (or multiple someones) could be trying to connect these machines to digital factory? Or perhaps trying to just establish an network connection to them inside Cura?
We have published instructions available listing the IP addresses of each machine so they can add the printers (all 6 of them) to Cura, but in my experience this doesn't require getting a confirmation code from them.
Any thoughts on why this is happening (and how to stop it)?