rachael7
-
Posts
160 -
Joined
-
Last visited
-
Days Won
6
Content Type
Forums
Events
3D Prints
Posts posted by rachael7
-
-
I didn't even know there was a material empty tag. The machine definitely does not use the amount remaining on the spool in any functional way. What it has is a sensor just inside the hole where you poke the filament into the material station. When the material is pushed in, it trips the sensor and the machine reads the tag to see what you just stuck in it. As the print is running, if that sensor trips back the other way, that means the tail of the roll just passed the sensor, so the machine takes that as empty and does the unload cycle on the remaining filament. The inside of the material station is such that if the machine kept printing past that point, the material could get stuck in there, so that's why it won't print the last meter or two of filament.
-
9 minutes ago, mbhsict said:
Is this an extra 40g that can't be printed because of the length to feed up the bowden tubes?
I'll measure a few more semi-used spools and compare scale weights to nfc readings and see if there if the 40g difference is consistent.
On more than one occurrence, we have had the printers say material is empty, when there looks to be quire a few loops of the spool left.It takes well over a meter of filament to get from the spool in the Material Station to the print head, maybe even more than 1.5m, which amounts to more than a few wraps left on the spool at the end. One might hope or expect that it would just keep pulling the filament in until it actually ran out at the print head, but it does not. As soon as the tail end of the filament passes the sensor at the entry point, the machine considers the material empty and whatever is inside the machine gets pushed back and usually coils back around the spool. I don't know if the amount left in the machine comes out to 40g, but it doesn't seem like an unreasonable number. I doubt they deliberately put extra on the roll for that purpose though, particularly since you could be using the filament from the back spool holder (which has a much shorter path) or on another machine like a 2+. More likely, in a high speed filament production line, it is just easier to err a little on the heavy side, rather than risk shorting a customer and facing a complaint or regulatory action.
-
2 hours ago, mbhsict said:
I'm using an Elatec TWN4, and it works with the Director software it comes with. I can read the tags to some degree, just not sure of which pages etc to look at for the material remaining. Was hoping the SpoolMaker program would make it a lot easier.
I'm not sure if Spoolmaker will be the right tool for that, but if you're able to read the registers, you can get the values directly and modify them if you wish. Here are the ones I know about, with the memory address followed by the parameter:
2E: Total spool weight
2F: Remaining spool weight
31: Printing time (in seconds). Only uses first three bytes, leave 4th byte alone.The data is stored in hexadecimal, with the weights in grams, if I recall correctly. It might be milligrams, but it's some multiple of grams, anyway. Hope this helps!
-
49 minutes ago, Slashee_the_Cow said:
I may regret saying this because of the existence of the "put up or shut up" concept, but in theory it might be possible to make a post-processing script which controls what order things print in all at once mode (if they're separate models). It's an idea I've been toying with in my head (for a completely different purpose, but same concept) but have yet to put finger to keyboard.
In theory, it certainly is. I feel like it is probably one of those "devil is in the details" situations though. Moving blocks around isn't too tough, particularly if they are commented and separated; but there are so many opportunities for issues, such as the final and preparatory rapid moves pointing to the wrong place. I'll spare you the "put up or shut up", but if you get something up to a beta stage, let me know and I'll be happy to help test and debug it with you.
-
1 hour ago, gr5 said:
I think it's "her". I'm pretty sure rachael and slashee are she/her.
Can't you then output it all as a single STL? Would that not help? I guess you already thought of that.
For me the "solution" issue is not so much that it doesn't work for "all at once" but that it's a workaround and only lets you choose the order if you want to print in one direction (left to right, right to left, front to back, back to front). And on top of that it doesn't help so much if you are printing a "grid" of objects as you can only say "row" order. Not part order.
Still, it's pretty damn simple, easy to understand, and even has a visual reminder of which way it will print based on the shadows. It's a pretty cool hack. I think it could help a lot of people.
Hopefully this will all be moot soon!
Yes, she/her, thank you. And yes, I have output the model as a single STL, but that still doesn't give any sort of control about what portions of the model print in what order since in that scenario it is all one object. There may be something I didn't try, but like you, this was one of many little annoyances that has led me to use Cura less these days, so it hasn't come up in a while. I'll play a bit more next time it comes up. Also, the workaround is for sure helpful and I might even use it myself for certain things. I didn't mean to imply it didn't have worth, only that it isn't really a "solution" per se.
-
2
-
-
18 minutes ago, Slashee_the_Cow said:
If you don't mind me asking, why? (and if you do mind me asking, you don't have to answer that)
I have had several cases where the design of the model was such that slicer-generated supports simply would not do the job, so I built the supports as objects in CAD. I've been using Solidworks for over 20 years, so sometimes I get better results designing the supports while I'm making the part. Anyway, when I brought the models in, each support structure was a separate object, along with the actual part of course. As is normal, the supports print at the same time as the part, so all-at-once mode is necessary. The print order became important because the slicer chose illogical orders for printing the supports and the part, which not only cost a ton of print time, it degraded the part by passing the nozzle over the model many more times than was necessary (some supports were inside the hollow part and some were outside). These were transparent PMMA (acrylic) prints, so the wall defects substantially affected the quality of the finished parts. Had I been able to set the print order, I could have saved perhaps 5% on the not-insubstantial print time as well as reducing the visual defects by 75% or more. I'll grant you that it is not a common use case, but it isn't hard to think of others that would be far more common.
-
It's not clear though, that's the point. I do very much care about print order in all-at-once mode, and as a user of this forum, when I see a "Go to solution" button, I expect it is solved. I certainly hope it is addressed in the next release, as has been suggested; but in the meantime, marking it as solved is deceptive and could result in less pressure to release an actual solution.
-
3 hours ago, gr5 said:
I marked @jeroent as "the solution" even though obviously it's not the perfect solution - it is by far the best I've seen at this point. Hopefully it's all moot when the next cura comes out.
Please remove this marking. It is at best a workaround, not a solution. It also doesn’t address the case of all-at-once printing. Marking it as a solution gives the false impression the issue has been resolved, when it most certainly has not been resolved for me and others printing in the more common all-at-once mode.
-
5 minutes ago, Slashee_the_Cow said:
If you're setting them as supports, they'll always print before anything else on that layer. Support is always the first part of a layer to print.
That isn't the problem. The issue is that because the supports are separate objects in Cura, it doesn't print the supports in any reasonable order. Imagine there are two rings of supports, one inside a vaguely ball-shaped object, and one ring outside. It makes sense to print all the inside ones or outside ones first, then cross the part once to print the other set. That minimizes strings and marks crossing the walls of the part. But what Cura does instead, no matter what I try, is alternate back and forth, one inside then one outside, so it repeatedly crosses back and forth over the walls of the part. I minimized damage as best I could with z-hop and retraction settings, but the material (PMMA) was an especially stringy one and all the strings getting dragged across the part negatively affected the clarity. I went round it for days, there simply is no solution other than manually editing the g-code, without an option to set the print order.
-
Where this really bites me on the butt is when I build custom supports for complicated parts. The supports are drawn in CAD, as separate objects, imported to Cura, and set to print as support. The workflow functions fine, but since it is a print all at once mode, the order in the list makes no difference, and because all the supports have to be in a specific position, I cannot move the parts around the plate to get them to print in the order I want. As I mentioned previously, this significantly impacts the quality of the part due to extra crossing of the perimeters and the associated flaws (made more obvious because I'm printing in clear material). There is no workaround and no alternative that I can find or that anyone can suggest. Manually specifying the print order is a feature that needs to be implemented. Pretty please?
-
These are the ones I bought most recently. They work fine as long as the spool is rotated to place the tag within the antenna. https://nfctagify.com/collections/stock-nfc-stickers/products/clear-nfc-stickers?variant=45259880857894
-
4 hours ago, Jasonjason said:
Are you sure you are actually seeing a closed loop temperature control?
I’m not sure at all, no. In fact, not long after that post I had to give up on the air manager altogether because it kept killing my long prints with random unrecoverable errors. -
On 5/15/2023 at 9:18 PM, gr5 said:
I think we do have it. Read above. It's the order you load the STL files. At least it used to be. I'm pretty sure it still is.
That doesn't really give us the ability to control though, if we're honest. Yes, you remove all the items from the build plate and load them again, perhaps; but what if you've already done a fair amount of prep work on the parts? Added per-part settings or support blockers, or other changes that you'd have to redo completely if you deleted and re-added the parts. I reject that as a "solution" - at best it is a workaround - but it is a clunky workaround that really isn't practical in daily use, especially when the proper solution should not be difficult to implement.
-
2
-
-
On 4/25/2023 at 3:31 AM, Gero said:
We have also had this error several times now. We were able to find out that it is not a connection problem.
For us, the error occurs when the print bed temperature is too low (below 60°C). Apparently the fan has its own monitoring. If it cannot measure the speed of the fan even for a short time, the printer stops printing immediately without being able to continue.
The error no longer occurs when the filter is removed from the Airmanager. Apparently, the air flow is significantly lower with the filter and thus triggers the fan monitoring much faster.
That is a fantastic bit of sleuthing, thank you for sharing. I was encountering the problem (before I disconnected the Air Manager) on prints with high chamber temps. That likewise would have produced a slow fan speed, so I suspect it was the same cause you discovered. I'm going to try it without the filter and see if that makes it reliable enough to use the Air Manager again. It's getting to be a real hassle trying to control the chamber temperature by opening the lid/doors just the right amount.
-
On 5/23/2023 at 8:18 AM, SanneM said:
We are aware of the issue and will prevent this from stopping a print in the upcoming firmware release
Apologies for the inconveniences, we take this feedback seriously
That is wonderful news, thank you! Will this be in the next version to come out? If so, do you have an approximate ETA? Or at least if it is a matter of weeks, months, etc? Thanks!
-
2 minutes ago, Dustin said:
You were probably subscribed to the "Stable" firmware branch, which would mean you wouldn't have gotten the notification for a "Latest" firmware branch update.
8.2.0 was released today to both "Stable" and "Latest" which is why you saw that.
Release notes here: https://support.makerbot.com/s/article/1667410781982Thanks, Dustin. My alert was for 8.2.0, but (before your reply) I could only find release notes up to 8.1.2 and your post is also titled 8.1.2, hence my confusion. Thanks again for the response and the link!
-
I did get an alert, but my alert said it was for version 8.2.0. Is there an 8.2.0 or is that just a faulty alert message?
-
On 4/25/2023 at 3:31 AM, Gero said:
In fact, we have disconnected our Airmanager from the printer for the time being because we have a few jobs to process and the Airmanager is not contributing to the reliability of the system at all.
As long as Ultimaker finds it necessary to let the firmware cancel the print job completely when this error occurs, I cannot recommend the Airmanager.
I had the exact same experience, random Air Manager errors that killed prints, often in the last few hours of day long prints. I worked with UM support for months, with no resolution. I likewise finally just disconnected the Air Manager. It’s inexcusable that it doesn’t have better error handling. It could at least keep trying to reestablish communications for 5-10 minutes. It could do that without significant risk, as the heat doesn’t build up that quickly. Easy solution that has not been implemented.
-
9 minutes ago, gr5 said:
I know many of the employees. I chat with a few of them almost daily. It's a small company. I know enough. They are trying to do the right thing.
I truly hope they are "trying to do the right thing". Unfortunately, their idea of what the "right thing" is may or may not agree with how we feel on the matter. Thus far UM has given no indication that they intend to return all, or even most, of the deprecated features, so they don't seem to be doing what I personally would define as "the right thing".
-
1
-
-
3 hours ago, gr5 said:
That's just not true. Don't be so suspicious. Ultimaker has nice people.
You don't even know that. You said yourself that you don't even work for UM, so you certainly have no special insight into their C suite meetings about long term plans. And sure, many of the people who work there are wonderful people, kind and doing their best to help. Lots of cops are lovely people too, but that doesn't change the fact that they work in a screwed up system and are bound to follow the rules and ethos of that system. And since you don't know the leadership ethos of UM, especially after the merger, whether the individual employees are "nice" or not is completely irrelevant.
What matters is the actions of the company. I've been using UM printers since the original flat-pack days and still happily run an UM2 among my other machines. I bought the S5 Pro Bundle with no reservations or hesitation whatsoever, and with every expectation of the same reliable performance and good service as my previous UM printers. I haven't gotten that reliable performance at all, and now I'm being not-so-subtly pressured to move to a walled garden environment where I will be dependent on the internet writ large and UM's servers specifically, in order to have all the functionality that originally came with my $10,000 printer. You can try to look behind the actions and discern motives all you like, but I am taking the actions at face value and listening to the other users on this thread who are similarly impacted and unhappy about the move.
You yourself go on to acknowledge the vulnerability of systems that rely on the internet and you casually disregard the concerns of people using medical, industrial, and governmental networks that still must work within those security requirements, whether you think those requirements are outdated or not. You post on these forums a lot and you've shared a lot of your time and knowledge (including with me), which is appreciated; but you should remember that you don't work for UM and you do not need to post on every thread. Your reflexive and logically inconsistent defense of the company, in the face of pages of angry customers with valid concerns, is unwelcome and not useful. Maybe take a break today, @gr5.
-
1
-
-
1 hour ago, nurban said:
What was the logic of removing these features from the web interface? Even if they're available somewhere else, having all maintenance information available to everyone on the LAN without needing special accounts, access, or software was extremely valuable.
The stated rationale was to unload the processors in the printer to make room for future capabilities. It seems to be related to the S7 release, so figure that in there somewhere. The unspoken, but logically likely, reason for removing the features was to force us onto their cloud platform where they can then try to tempt/force us to upgrade to a paid level of the cloud service. It hasn’t even been made clear, to me at least, if we get the reporting features back with the free version of Digital Factory.
UM has made it quite clear that they have no intention of rolling things back to where they were. They grudgingly gave us back the ability to reprint from the queue, but that appears to be all they’re willing to do for their longstanding customers.
It is definitely disappointing, there’s no question about that. I have stronger feelings than disappointment, but I’ve said what I needed to unthread. I will say that while I’m not prepared to yeet the machine out the window just yet, this whole incident has so soured me on UM as a company, that I simply cannot envision myself ever buying another of their printers, and I’ve been with UM since the early days.
-
4
-
-
2 hours ago, Smithy said:
The tool connects via SSH to your printer, so you have to enable the developer mode before you can use the tool. If the firewall blocks SSH too is a good question, I have never enabled my firewall.
But I have tried now some commands with FW 8.1.1 and it is working. I tried cleanbed, sshserver, leveling.
Yeah, the firewall blocks all local access. With the firewall on, the printer will only talk to Digital Factory and nothing else.
-
1
-
-
34 minutes ago, tomnagel said:
Not meant to be condescending, but you may want to read this article: https://support.makerbot.com/s/article/1667411337398
I’ve read your article and it does not resolve my concerns.
1. Data breaches happen to many companies, some far larger than UM, and it is unreasonable to expect that UM will never suffer such a breach.
2. That only addresses security, not functionality. If UM servers go offline, the ability to use the printer is compromised. If UM goes out of business or discontinues Digital Factory, the functionality is gone for good.
3. Many engineers making purchasing decisions about 3D printers have no control over the IT and IP protection policies of the companies they work for, so no matter how many articles UM writes, those people will be unable to follow UM’s desired approach.
-
2
-
-
And I will add that repeatedly lecturing us to read the security documentation is exactly the sort of response that comes across as arrogant and condescending. The people in this thread don't all have control of their companies IT policies. Many of them told you that they aren't allowed to connect their printers to the internet at all. And you keep lecturing us to read your security documentation as if that is going to change anything.
-
2
-
Read/Write NFC Tags
in UltiMaker 3D printers
Posted
I agree, that API flag is likely your best bet for an alert on filament directly. Do you also have an alert for the printer status? There is a parameter exposed to the API that will tell you if a printer is stopped mid-print, such as when filament runs out. That seems like a worthwhile alert trigger as well, particularly since it would also catch other issues that require operator intervention.