Random Mode buffer ran out

Comments

37 comments

  • Avatar
    Jonny Yeu

    Hey Donovan, thanks for this information. We've seen this issue recently and are currently looking into the problem. Could you please share your OctoPrint log file with us? This may provide us with additional information.

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    Recently, as in since the first firmware version of the Palette 2 available to customers.

    0
    Comment actions Permalink
  • Avatar
    Donovan Meyers

    Hey Jonny,

    Sure. I'll send it to jonny@mosaicmfg.com.

    This print started at 2019-02-17 19:05:59,521 and I cancelled it at 2019-02-17 22:59:54,425.

    I also shot some videos, but they basically show exactly what I described.

    Is there a list of known bugs somewhere? I know I'm not usually the first to discover something and it's reassuring to know that you're already working on it. I know there's something for Canvas but is there for Palette and the plugins?

    0
    Comment actions Permalink
  • Avatar
    Donovan Meyers

    @Kurt, I knew about those but hadn't seen reports of it happening in Random Mode. Might be the same issue, might be different.

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    Yes, I think it was a good idea to report it.

    My comment was more targeted to the "recently" remark in Jonny's respond :-) (yes I'm still a bit grumpy after re-watching their pre-launch promotional stream).

    0
    Comment actions Permalink
  • Avatar
    Donovan Meyers

    As a test I factory reset the P2P, reinstalled the firmware, calibrated (twice), and reran the same gcode file in Random Mode.

    I didn't witness the gradual decline this time but when I came back the extruder was grinding, the buffer was empty, and the buffer switch light was on constantly.

    Calibration values were 2.44/39.26, and 2.4/39.08. SPC seems to stay the same or within a narrow margin, but PPM varies from 38.58 to 39.26.

    I keep wondering if the PPM is partly to blame, telling the Palette that there's more filament in the buffer than there is. But like I said, it shouldn't be ignoring the buffer switch, IMHO. That should be a red flag, and a trigger to pong.

    Maybe I'll do a smaller print, maybe just normal multicolor, so it can do some pongs. Maybe it will sort itself out.

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    I just had this happen during a regular multi-material print to. So seems like the palette will decide to randomly stop feeding out filament in any mode.

    0
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Hi Donovan, thanks for sharing this information with us. We're still looking into this issue to try and replicate it on our end, but what is your printing speed when using random mode? Your PPM and SPC look within range, but I'm wondering if speed is affecting this. We do plan on building in the ability to slow down the printer when Palette is creating a splice, and expect to have something released in the coming weeks.

    0
    Comment actions Permalink
  • Avatar
    Donovan Meyers

    I print at 40-50 max, and I have a Pro, so I don't think it's that it couldn't keep up. I watched it splice and not run out. It was PLA<->PLA at default 0/0/0.

    That slow-down feature does sound pretty cool, though, since I did run into issues when I was splicing PLA<->PVA at 5/3/3. It couldn't keep up. If the printer could slow down or wait automatically, it could help.

    Anyway, I'm wondering if the reports I'm seeing on Facebook of Palette creating too much filament are the flip side of my issue. Some calibration is off and Palette doesn't know how big the buffer is, and makes too much or too little filament until either the outgoing tube pops off or the filament is wrapped tight around the buffer switch.

    Of course I'll take this opportunity to repeat that it should never ignore the buffer switch. :) Buffer switch on = make filament.

    But I wonder if something is going wrong when I calibrate, either in how the Palette is interpreting what happens or maybe I'm doing it wrong (pulling too fast, etc.).

    And please give us a way to manually set things like PPM and loading offset!

    1
    Comment actions Permalink
  • Similar issues here. Print between 40-60mm/sec and am also experiencing buffer running out, buffer switch triggered, and no filament fed into buffer.

    Prints are large, 31 hours and 600g filament each. Seems to occur after numerous hours printing. Buffer loop gets smaller and smaller. Printer takes 3mm out of buffer, and P2P only feeds in .5-1mm. Initially feeds similar to demand. 3mm in for 3mm out. Self calibration appears to be out of sync. Only way to fix is to clear to factory defaults.

    Unit purchased to reduce waste and provide continuous filament. This is not meeting the requirements which this was purchased for.

    1
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    We’ve heard a few instances where users are having issues with the buffer collapsing in Multi-spool and Random modes since the last firmware update (v4.0.3). We suspect that this is an issue with ‘ponging’ when using these modes and are working on a fix that will be available on an update we plan to release soon. We did not see this error in previous firmware versions, but there may have been something in the latest update that is causing this buffer issue. We appreciate your patience while we investigate this error.

    To help ensure that this is not an issue with Palette’s hardware, I would suggest running a Palette calibration to ensure that your unit is tuned to your particular filament: http://mm3d.co/calibrate-p2

    We do plan to enable the ability to adjust calibration values in the future, but for the time being, we do ask for your patience while we fix this bug.

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    I reported this 2019-01-14 here, and it was also reported 2018-12-14 here, so I find it very puzzling that you write "We’ve heard a few instances where users are having issues with the buffer collapsing in Multi-spool and Random modes since the last firmware update (v4.0.3)".

    This has been all over your forums since pretty much day one. It happened to me on the first multi-spool print I ever tried.

    That there is technical issues that are hard to find and fix I can tolerate as long as I feel an honest attempt at fixing it is being made. Being flat out lied to and constantly being fed bullshit I can not tolerate. Especially not after I re-watched your promotional pre-launch stream.

    I don't know about Canada, but here that kind of false advertisement would be criminal. I would really like to hear a rationale behind the statement about the buffer size.

    This product is not what we was promised. Most of it is software issues that might eventually be fixed, but two major issues are in hardware. One is the way to small buffer. That can't be fixed in software. But it can be worked around. The other is that there is no buffer-full sensor, so ponging have to go in a direction that guarantee that multi-spool prints will fail every now and then unless printed at less than 25mm/S so the cutter-to-splicer distance provide enough buffering.

    What are your plans for addressing this issues? Without finding a fix for this, you have charged a lot of money for a product that you did not deliver.

    2
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Hi Kurt, when we discussed the issues you were having over e-mail, the overall issue was due to the high speeds that you were using. With both Rachael and Donovan, they're printing at lower speeds, so the issue seems to be related to ponging in these modes. As I've mentioned previously, we're working on a fix for this in the next update. As you can see from other users (https://twitter.com/paletteprinted), people were able to use Multi-spool, Random, and other non-calibrated modes with no issues. There seems to be a bug in our last firmware update which we're currently working to address.

     

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    This is just not even believable.

    Why do you totally ignore everything I write and just give completely random answers?

    What made you think I was talking about the e-mail discussion we had? Which also was an endless list of questions from me answered with what appeared to be completely random sentences crafted as a smoke screen to avoid actually answering any of the questions. Which is why I eventually just gave up and stopped replying. It was just a complete waste of time.

    I even linked to the page where I mentioned the problem with multi-spool. That clearly was not enough, so let me quot it here:

    "I then gave up on multi-color printing and decided to try the multi-spool option to empty a few almost empty spools on a single-color print. I loaded up 3 spools in input 1-3 and started a print.

    Half way through the first layer it simply stopped feeding in new filament from the first spool. The printer drained the buffer, the blue light came on, and the printer extruder started grinding away on the filament.

    I'm soon ready to take a sledge hammer to my Palette 2...".

    No high speed here. Given it failed during the first layer it was probably less than 20mm/S. Just spontaneously stopped feeding filament with no splicing in sight.

    And how dare you replying again to the claim that multi-spool mode is completely broken by design by linking to customers that have used that mode without it failing?

    Some quick calculations show that it can not be guaranteed to work with print speeds above 24.8mm/S. It should be blatantly obvious that most prints will still succeed, since only those with an unfortunate timing will fail. But having a design that leaves weather a potential multi-day print will succeed or not up to luck is a totally broken design and needs to be fixed.

    Also the bug we are actually discussing here does not happen 100% of the time. It is random. And it is not something new in the latest firmware update, it has been reported repeatedly since the first firmware version! So again, responding to it by linking to success stories are utterly stupid!

    And I'm still waiting for an rationalization of the blunt lies that was presented about the buffer size in the promotional stream.

    Like I said, I can be very patient when I feel that an honest attempt is being made to rectify a problem. But that is not at all what I see here. All I see is denial and smoke screens attempting to cover up for the obvious flaws that this product have. And I'm very frustrated when I see it stated that most resources are being spent on reinventing the slicer wheel when there is so many issues with the base functionality of this after all rather expensive product.

    2
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Edit: fixed link address

    Hi Kurt, I’m happy to answer any questions you may have as demonstrated by our lengthy e-mail thread. The last correspondence that we shared was concerning the speed of which Nylon can print safely, and I provided the reasoning and calculations on how we found these speeds. Your last message here asked about what we’re doing to solve this issue and I’ve responded that we’re working on a solution. I don’t have anymore information at this time except that we’re aware of this bug and are looking into it.

    The issues that you were seeing in both linked comments were addressed previously as they were due to the original buffer switch issue which was experienced in all print modes and was fixed with a previous firmware update (http://mm3d.co/p2-fw-notes - Dec 21, 2018). The new issue we’re seeing now is a ponging issue that occurs only in Multi-spool and Random modes.

    Also, as shown in our e-mail thread is that your calculations do not take into account many assumptions that come with 3D printing. We can argue about this again if you’d like, but the numbers that we provide on our website (http://mm3d.co/p2-speed) are based on tests that we’ve run on the various printers and filaments that we use in our office.

    We’re also working on other tools to help with printers that may have issues with unfortunate timing, including the ability to slow down the printer when a splice is occurring. This is based off of Tim Brookman’s fork of the Palette plugin, and we expect to have this available in the coming weeks. If you'd like more information about this, I can link the original Facebook post.

    We appreciate your patience, and we are working on a fix for this issue. You can see that as a company, we work to improve the overall experience by sharing updates and fixes as soon as possible. We’re updating CANVAS on a weekly basis and provide firmware and plugin updates to address customer feedback when needed. We’ve even provided a recent update for Chroma so that previous Palette owners can experience new features and benefits. We’re aware of this particular issue with ponging and we’re working on a solution. Once I have more information, I would be happy to share.

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    Really...

    Again, you are just flat out ignoring what is being said and give the answer you think is most likely to get you out of the pot hole.

    Regarding your last reply on how you came to max speed of 280mm/S with nylon, I just gave up. After reply after reply where you kept decreasing the time you claimed was needed to splice nylon you again replied with a time that would make it physically impossible to reach that speed, and you had at that point demonstrated so many times that you did not at all understood the problem, so I just left it.

    And no, I still do not find it satisfactory that the numbers you state are not real numbers, but inflated numbers based on unstated magic that in practice makes most real prints attempting to use those numbers fail. That is called lying to your customers.

     

    "The issues that you were seeing in both linked comments were addressed previously as they were due to the original buffer switch issue which was experienced in all print modes and was fixed with a previous firmware update (http://mm3d.co/p2-fw-notes - Dec 21, 2018). The new issue we’re seeing now is a ponging issue that occurs only in Multi-spool and Random modes."

    WHY DO YOU NOT READ WHAT I WRITE BEFORE REPLYING??? FFS! I wrote "...The printer drained the buffer, the blue light came on...". Does that sounds like the buffer switch jam bug? Or do you think maybe the blue light would not come on if this was caused by the switch jam? I even wrote up here that I made that post 2019-01-14. And you reply that this was a different issue because that issue was fixed in a patch 2018-12-21. Really? Can you please at least read what you are supposed to reply to before you make your next reply?

    Sorry for being so aggressive, but this is getting utterly ridiculous.

    1
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Hi Kurt, the information I provided in our last e-mail exchange is based on in-house testing. The 'unstated magic' used are assumptions and variables that affect all 3D printers.

    To clarify, the original buffer issue caused the blue light to turn on even when the buffer was pressed. The issue noted in January was due to error 43 (screen freezes) and has also been addressed in a recent update.

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    "Hi Kurt, the information I provided in our last e-mail exchange is based on in-house testing. The 'unstated magic' used are assumptions and variables that affect all 3D printers."

    Yet, your numbers make all 3D printers fail if you try to use them. Fudged numbers are worthless. Only real data can be used to make correct decisions. I don't know whose ass you keep pulling your numbers out of, but I know it's not a very reliable one.

    "To clarify, the original buffer issue caused the blue light to turn on even when the buffer was pressed. The issue noted in January was due to error 43 (screen freezes) and has also been addressed in a recent update."

    What? Really? What am I even supposed to reply to this...

    The issue noted in January was due to error 43 you say? The issue that I noted? The post where I wrote "It prints for a while and then I get error 43 before it cut the filament and stop splicing in more. I then gave up on multi-color printing and decided to try the multi-spool option".

    That issue was caused by error 43?

    The issue that occurred when I stopped trying the print that caused error 43 and decided to test multi-spool instead? Where I did not mention anything about error 43 at all?

    What even do "the original buffer issue caused the blue light to turn on even when the buffer was pressed" mean? That just looks like jibberish. What was pressing the buffer?

    I thought the issue was that the button would not be depressed because it would put pressure directly on top of the lever making it unable to pivot to either side. And that it was solved by always slowly inject filament into the buffer to assure that the lever would always tip over.

    Either way, if the blue light was on, that would mean that the switch had registered that the buffer was empty, would it not? How else would the light turn on? And if so, why would you attribute the fact that the P2 stopped feeding filament to a problem with the switch?

    Again, you are just replying random BS with no relevance to the questions being asked.

    1
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Hi Kurt, as I mentioned before, we can continue to argue about how these speeds were calculated but I can assure you that our engineers have shared these values based on hours of testing and data over numerous scenarios. We have over 10 different brands and models of printers in-house at any time along with hundreds of spools of filament, and the tests were run using these resources.

    To further clarify, no, the original issue was not that the plastic tab would remain stuck as this is a hardware problem. The original buffer issue was that the blue light would turn on, meaning that the switch was triggered, and the firmware would not register this properly. This is why a firmware update was implemented. 

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    "our engineers have shared these values based on hours of testing and data over numerous scenarios"

    Which is what I have complained about the whole time. Your engineers are not doing any engineering. They are basing everything of trial and error. Unfortunately that is a piss poor substitute for engineering since you will not be able to make all the errors.

    "We have over 10 different brands and models of printers in-house at any time along with hundreds of spools of filament, and the tests were run using these resources."

    Like the one you have on film during the promotional stream that snap the filament while printing at 50mm/S with the same buffer utilization that we all see? Of course who would expect a 50mm/S print to succeed when the claimed safe speed for PLA on a non pro is 63-103. Only a fool would read those number and be stupid enough to attempt a print at 50mm/S.

    "The original buffer issue was that the blue light would turn on, meaning that the switch was triggered, and the firmware would not register this properly"

    Yes? Isn't that exactly what the problem was in this case to? That the blue light is on but filament is not being produced? You are really not making any sense at all now. You appear to be flailing all over. First you say that this issue is not related to the issue that has been reported since the beginning of time, since that issue was with the buffer switch, and now you say that that was not really a problem with the switch, but just the firmware's handling of the switch, and then we are full circle back to the same issue that we are discussing in this thread.

    And I'm noting that you are still ignoring my inquiry about the blunt lies from the promotional stream. 

    1
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Hi Kurt, we respect your opinion on our engineers work and can assure you that engineering is being done in our offices. If you believe that these are 'blunt lies', this is your opinion and is unlikely to change regardless of my response.

    Yes, this printer is included in the models that we've tested on. The promotional stream was released before any firmware updates were released and the issue you noted was the catalyst for the speed tests.

    As stated numerous times, this new issue has to do with ponging, which is Palette's way of measuring the filament output via the encoder. It is not the same issue as triggering the buffer switch and not receiving the signal. 

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    "Hi Kurt, we respect your opinion on our engineers work and can assure you that engineering is being done in our offices. If you believe that these are 'blunt lies', this is your opinion and is unlikely to change regardless of my response."

    Well, I back up everything I say with math. When you back your arguments with facts they are no longer opinions. You are just presenting anecdotes. My mind is easily changed with facts. Yours are clearly not.

    "Yes, this printer is included in the models that we've tested on. The promotional stream was released before any firmware updates were released and the issue you noted was the catalyst for the speed tests."

    The time to splice is the same as in the latest FW, the buffer utilization appears to be about the same, and the failure mode seems to be the same as I and others see. What has improved?

    And what about the statement on buffer size:

    "There is some really fancy math that goes along with this that the team has explained before, but because the minimum piece length in palette 2 is 8 centimeter 12 is actually more than we need. And in fact making the buffer bigger wont lead to faster printing. And that is a bit counter intuitive. But they found that having I think it was anything over 10cm is more than enough that we need to make sure that palette 2 can generate filament at it's own rate for the printer but keep up to the average print speed of the printer from those speeds.".

    How are you defending this? This is what I have been talking about when I want you to comment on the blatant lie presented about the buffer size. To me that sentence does not appear to make any sense at all. I explained why I believe so here. Saying that 10cm would be more than enough proves that he (or rather the engineers he refer to) either have no clue about the issue, or that he is being knowingly dishonest. In other words are lying. So what is it? Dishonesty, or incompetence?

     

    "As stated numerous times, this new issue has to do with ponging, which is Palette's way of measuring the filament output via the encoder. It is not the same issue as triggering the buffer switch and not receiving the signal."

    Now you are back to outputting random meaningless words again, hoping I will grow tired and go away.

    1
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Hi Kurt, if you'd like to continue this conversation, please feel free to send me an e-mail and we can continue on with our thread. At this time, we're moving away from the main issue, which is the firmware bug that we're seeing in Multi-spool and Random mode.

    Concerning the buffer size, we've found that this statement is true for the tests that we conducted. Please feel free to share your findings.

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    "Hi Kurt, if you'd like to continue this conversation, please feel free to send me an e-mail and we can continue on with our thread. at this time, we're moving away from the main issue, which is the firmware bug that we're seeing in Multi-spool and Random mode."

    With you not being able to (or willing to) give a real answer to any questions what so ever, that would be pretty meaningless.

    "Concerning the buffer size, we've found that this statement is true for the tests that we conducted. Please feel free to share your findings."

    My findings are that this are absolute bullshit, and that if your engineers have conducted tests that confirm that statement they are clueless and incompetent.

    I have built an external buffer that allow me to print several times faster than with the internal buffer alone. Calibration is an issue, because it does not prevent the P2 from reading false pings while the buffer is being drained. But I can easily print at 120mm+/S without starving the printer with objects that would fail at 60mm/S before. Both speeds are "slicer speeds" BTW, with 3000mm/S^2 acceleration. So not real average printing speed. So saying that 10cm would be more than enough is absolute bullshit.

    1
    Comment actions Permalink
  • Avatar
    Redemptioner1

    Sorry Johnny but there is a bunch of feedback you need to take on-board and more questions to answer:-

    •  I agree whole heartedly with all of Kurt’s statements
    • The issue with buffer runout in multi-spool and random prints has been around since the beginning(I reported it back 2 months ago long before firmware updates), you just need to accept this is the case and move forward with resolving it. There is no need to get defensive with your paying customers as you just make yourself look like a fool and make the customer frustrated. Random use to take a lot longer to fail, but in recent updates it has been made it as bad as multi-spool.
    • Read the post carefully before you reply (maybe in your case you need someone to read the post for you and explain it to you before you reply), I have lost count how many times I have asked and seen other people ask you to do this, 101 of customer service champion.
    • You know people can search the forum right? We can check/reference your previous posts hence why you have been called out for misleading/lying to us.
    • When there is an issue raised by a paying customer, don’t dismiss their issue by referencing someone not having the issue, this is discourteous and very disingenuous.
    • When you ask people to leave the forum and take the discussions/complaints offline it just screams to customers that you either don’t want to answer the questions or you are trying to convince the customer to take the conversation off a public forum in order to hide it. In both cases its unacceptable and you really need to stop asking people to do so. If a customer has a question then others probably have the same question too, if you are getting a pounding for problems with you your product then you either need to fix it or stand there and be prepared to cop the flack and properly explain why you are stuffing around your customers.
    • Have you worked out what is causing the issue?
    • When do you expect to have a firmware release to fix this?
    • What mitigation strategies have you taken to prevent this ongoing failed firmware releases (I suggest sending out some free units and a bunch of filament to people who print more than 300gm prints and have real “experience” in using 3d printers (something you team seems to be very lacking in) to do a bunch of testing.
    • Don’t reference a successful tiny/small prints, it is hardly a relevant “test” printing a tiny 100 splice print and saying others have had no issue. No-one really cares if a 15g print fails or not, different story when a 1kg print fails. The fact that you are not showing any of your own “successful test prints” does not bode well for you making statements like “We have over 10 different brands and models of printers in-house at any time along with hundreds of spools of filament, and the tests were run using these resources”.
    • This is a $600USD machine, why are there so many problems if you have done all this “testing”? (clearly your “testing” falls well short of what is needed!)
    • In what world do you think 24.8mm/s is an acceptable print speed when you advertise 70mm/s?  A 3DBenchy at that speed would take 24hrs to complete which is just ridiculous. I have already had to reduce my delta print speeds by at least 2/3, running at your “successful” print speed will mean going down to nearly 1/10 of the printers speed which is simply unacceptable.
    • A “buffer full” switch would have resolved many of these issues I am sure, along with making the buffer the majority of front facer area (over the top of the motors), I guess that ship has sailed now…..
    • And in fact making the buffer bigger won’t lead to faster printing. And that is a bit counter intuitive” -  Do you even understand that the buffer length is what is setting the speed you can print at right? (well technically it is the time to splice which is managed through buffer length). Of course increasing the buffer length increases the speed you can print as the splice time is basically the only limiting factor to print speed (within reason), if you can explain to me how it isn’t then I will pull down all my posts, but unless you can change the law of physics I don’t see how you will manage this. I take it your engineers don’t know how to do basic maths? Here is some maths I think even your engineers should be able to understand   

    ==>A printer is using 50mm of filament in 5 secs, so to empty the 100mm of filament in the buffer (being generous) it will take 10 secs. If the palette2 takes 15 secs to run a splice cycle then in 10 secs you will run out of buffer with 5 secs still to go on the splice

    ==>Change buffer to 250mm and keep printer speed at 50mm of filament usage in 5 secs now we still have 15 secs left in the buffer after a splice

    ==>If  we double the print speed to 100mm of filament used per 5 secs and use a 250mm buffer we will still have 5 secs of buffer left after a splice and we have doubled the print speed.

    • Adding an additional 2-3 cm (or more) to the length of the buffer when a splice goes to start would give the needed additional buffer length to sustain the “sales specifications”, I am sure if the buffer was full at beginning of splice we would see up to 90mm/s print speeds (that’s unmodified print speed with 0.4m noz and 0.2 layer for those who struggle with accepted standards).
    • You should be able to easily look for a current spike on the palette2 output motor to detect when the buffer is filled (assuming you have not used $3 motor drivers which is unlikely considering how much noise the motors make and the fact you put a Pi that is recommended not to be use by Octoprint in the Hub in order to run Octoprint), then draw back the amount needed for splice process (about 10mm) and ensure almost double the buffer is available during a splice, just a no brainer……
    • You guys need to opensource the firmware as you are doing a terrible job. If you at least exposed a bunch of the palette 2 attributes in the menu to be manually edited it would not only allow people to tune their palette 2 to their needs it would also allow us to get around a bunch of your poor “engineering” choices (i.e. set max and min buffer lengths).
    • You do get that a major problem/issue is not a “bug” it is a major defect? I am not sure if you have a Test  Manager, if you do they need to get kicked to the kerb, if you don’t then you need to go hire one as a priority. If you are doing all this testing, how are you releasing software updates that are making things worse?
    • I am fortunate (or unfortunate depending on how you look at it) to have multiple printers and multiple Palette 2’s, I also have friends and customers with Palette 2’s  and they all show the same identical issues so the problem lies with the product and not the users. How can you call poor/ineffective control of Palette2’s splicing “unfortunate timing”, there is no unfortunate timing just poor print control? Print something longer than 1-2 hours in your “Tests” and you will find it is not poor timing.
    • It should not be hard with the encoder info to work out how far it is to the next splice and the current feed rate to identify the need to slow a print down to enable the splice time to occur without hitting the end of the buffer. I would hazard a guess the amount of calculations are limited with the tiny Arduino setup you decided to go with but there should still be enough processor overhead to do this calculation.
    • I strongly support the call out to stop working on Canvas (being a free tool that has no real impact on Palette 2) and put all the time and resources you are wasting on this profitless product at the moment and refocus everything on the item you have already charged customers for and ultimately are making money out of. Canvas will be a nice toy when you have the palette 2 working without a single issue, but there is simply no excuse for continuing to waste time and money on Canvas when you have a defective new product, you have charged money for, out in the market. Project Management 101 says finish the “must have” requirements before you start looking at the “nice to have” requirements.
    • Do you realise how bad it is that you are effectively promoting a third-party open source and free software that has more features (that work) and is doing a significantly better job of controlling the Palette than the manufactures own software? Doesn’t this tell you to stop wasting time and money on Canvas at the moment when open source developers are out performing and out classing your product?
    • Concerning the buffer size, we've found that this statement is true for the tests that we conducted. Please feel free to share your findings.” If this statement was actually true and you are so confident of this statement being true why don’t you put up some evidence to support it, clearly the evidence that has been supplied to you already does not support this position (nor does the maths or basic physics principles). Put up here some (all) of the printer and slicer settings and some sliced files with these settings for these 10 printers you have “extensively tested” on and I (and I am sure Kurt will be happy to as well) can put this “statement” to a real test. One look at the G-code will tell us how much fibbing/understanding is going on in your team of “engineers” and you won’t be able to bluff this as running the analysed files through the printer will confirm if you are fudging the numbers. If you are certain of your statement then put your money where your mouth is, if you are saying you have done this “testing” and we are wrong then if I/we test the details and they are found to be bogus then you agree to refund the cost of the palette2 without return, if you are correct then all the visibility of this issue will be removed and you won’t hear a peep from us again
    • “this is getting utterly ridiculous” – That’s an understatement!

     

    Just to be clear, this is not moving away from the thread, this is taking up the fact that you are lying and not answering the questions asked of you in the thread. Put some evidence behind your opinions to remove any BS or ambiguity like Kurt has done for you.

     

    1
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Hi Redemptioner1, I’ve responded to similar questions in another forum post (https://support.mosaicmfg.com/hc/en-us/community/posts/115000952728-Let-us-know-about-your-Palette-experience-) and will reiterate certain points.

    • As mentioned numerous times above, the current issue is related to ponging and how Palette assesses the amount of filament that is passing through the output. The previous issues with buffer runout were due to firmware issues where a triggered switch would cause screen freezes or would not provide an accurate response.
    • Accusations of lying and lack or respect should be taken seriously, and examples would be appreciated. I feel that I have provided patience and respect in my responses even when it may not be reciprocated.
    • I am not dismissing any issues and I am happy to provide assistance. However, the points above have been discussed in length via a separate e-mail conversation. My offer to continue this conversation over e-mail is because we already have a thread in which we’re discussing these points and because the purpose of this original thread has been lost.
    • We have many users who fulfill the criteria of printing more than 300 grams and have real 3D printing experience. You can ask about their experience directly on our Facebook group: http://mm3d.co/fb
    • Within this group is our weekly print contest, where you can see that these prints are not tiny or small: https://www.facebook.com/groups/mosaic.users/permalink/332612127375362/
    • You can find our own successful prints on Thingiverse (https://thingiverse.com/mosaicmanufacturing) and Instagram (https://www.instagram.com/mosaicmfg/).
    • Although a large amount of testing is done before the launch of a product, almost every product experiences issues once it is available to a large number of users. This is why even large corporations such as Apple or Google provide updates to their products after launch. What is more important is how the company reacts to these problems, and we provide constant updates and fixes based on customer feedback. We actually just updated the CANVAS Hub plugins today and released a firmware update two weeks ago. We even provided a Chroma update on Feb 19, 2019.
    • The print speeds listed on our website (http://mm3d.co/p2-speed) are based on the following criteria: 2mm layer height, 0.4mm extrusion width, 1.0 extrusion multiplier, and default/recommended splice settings (http://mm3d.co/p2splice-tuning). Your 24.8 mm/s print speed suggestion is based on Kurt’s calculations, not our own, and I’ve noted that this ignores certain assumptions and variables used in our calculations. These are also ignored in your calculations.
    • A full buffer causes other problems with certain printers and settings, including retractions. We’ve instead provided a speed variable that can slow your printer down when a splice is created. This is included in the latest CANVAS Hub plugin update.
    • Concerning the buffer size, I think it’s obvious that increasing the buffer size (and therefore overall physical size of Palette) would allow for faster speeds. If the buffer allowed for 1 meter of filament, then you could print at the speeds that you’re suggesting. Our goal is to provide a compact solution that can be easily attached to a 3D printer. Based on the physical constraints of Palette’s hardware, increasing the buffer from 100 mm to 120 mm would not lead to faster printing. If your suggestion is to create a physically larger Palette in order to cater to higher speeds, we would respectfully disagree and suggest that the smaller size and lower cost are more important to a large majority of our users.
    • I’m not aware of a call out to stop working on CANVAS, and it does have a major impact on enabling Palette 2 to print in multiple colors and materials. Concerning the third-party open source software, this is being developed in conjunction with our team and support of Palette users. We’re happy to continue supporting our users who are actively trying to improve on resources we’ve provided.
    • Once again, our engineers and entire team dedicate their time and livelihood to Palette and the entire suite of Mosaic products. I do not appreciate insults to their hard work in and commitment to creating an innovative solution for multi-color/material printing.

    Returning to the original issue of this forum post, we are aware of the issue in Multi-spool and Random mode and expect to have a firmware fix available. If you require any clarification on any of the points above, please feel free to e-mail me directly at jonny@mosaicmfg.com or we can schedule a phone or video call.

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    "As mentioned numerous times above, the current issue is related to ponging and how Palette assesses the amount of filament that is passing through the output. The previous issues with buffer runout were due to firmware issues where a triggered switch would cause screen freezes or would not provide an accurate response."

    You where the one who spread this thread into a million paths by constantly reference irrelevant stuff from our e-mail conversation. Like normal, you had no relevant arguments so you found something random to reply.

    "Accusations of lying and lack or respect should be taken seriously, and examples would be appreciated."

    Yes, that is something that should be taken seriously. Mosaic and you should be ashamed for first lying to us, and then coming with accusation back without providing a single evidence against the accusation.


    As for examples, we can start with the statement about the buffer size. Then you can tell us how printing above 24.8mm/s in multi-spool mode work without risking a buffer underflow.

    "I feel that I have provided patience and respect in my responses even when it may not be reciprocated."

    You must be one of the most disrespectful persons I have ever conversed with. Yes, you appear to be patient, but only because you will not be the one saying the last word. Your replies are all 100% worthless. They answer none
    of the questions being asked, and are generally just a bunch of denials that the problem exists at all.

    "I am not dismissing any issues and I am happy to provide assistance. However, the points above have been discussed in length via a separate e-mail conversation. My offer to continue this conversation over e-mail is because we already have a thread in which we’re discussing these points and because the purpose of this original thread has been lost."

    WHAT THE FUCK???? YOU ARE THE ONLY ONE HERE THAT KEEP REFERRING TO THE E-MAIL CONVERSATION! ARE YOU REALLY THIS DENSE? OR WHAT IS GOING ON? I ASKED YOU THE FIRST TIME YOU BROUGHT UP THE E-MAIL CONVERSATION, WHY YOU DID SO SINCE
    IT HAD NO RELEVANCE TO THE QUESTIONS I ASKED, YET YOU KEPT ON COMING BACK TO IT, AND NOW YOU DARE TO WRITE THIS? FFS!!!

    "We have many users who fulfill the criteria of printing more than 300 grams and have real 3D printing experience. You can ask about their experience directly on our Facebook group: http://mm3d.co/fb"

    Are you for real? What does it matter that it sometimes succeed when simple math proves that it don't? Real math, not Mosaic math especially tailored to make P2 look like it works.

    "Within this group is our weekly print contest, where you can see that these prints are not tiny or small: https://www.facebook.com/groups/mosaic.users/permalink/332612127375362/"

    And this is relevant because...?

    "You can find our own successful prints on Thingiverse (https://thingiverse.com/mosaicmanufacturing) and Instagram (https://www.instagram.com/mosaicmfg/)."

    Are this images supposed to be useful in any way without any information on how they was printed? Like maybe print speeds? And you can list examples of prints that succeeded til the heat death of the universe. It does not
    change the fact that you either have to print way below your advertised speed, or hope to be lucky.

    "Although a large amount of testing is done before the launch of a product, almost every product experiences issues once it is available to a large number of users. This is why even large corporations such as Apple or Google provide updates to their products after launch. What is more important is how the company reacts to these problems, and we provide constant updates and fixes based on customer feedback. We actually just updated the CANVAS Hub plugins today and released a firmware update two weeks ago. We even provided a Chroma update on Feb 19, 2019."

    This is just really really sad. How low are you prepared to let yourself sink?

    "The print speeds listed on our website (http://mm3d.co/p2-speed) are based on the following criteria: 2mm layer height, 0.4mm extrusion width, 1.0 extrusion multiplier, and default/recommended splice settings (http://mm3d.co/p2splice-tuning). Your 24.8 mm/s print speed suggestion is based on Kurt’s calculations, not our own, and I’ve noted that this ignores certain assumptions and variables used in our calculations. These are also ignored in your calculations."

    Ok, now I'm sure. You can't be for real.

    No FFS, 24.8mm/s was NOT based on MY MATH! It was based on math. Math is a universal thing, and you are not allowed to use a special branch of math specially designed to make your equations give the answer you hope for.

    And why are you just throwing out statements like this without any kind of backing? When have I come to you with a claim without also showing you the equations and calculations including all numbers I used to get to that conclusion? When have you done the same to me?

    Which factor was missing in my calculations that would allow the P2 to look into the future and know when the current spool in multi-spool mode would run out and foresee the need for a splice so it could make sure the buffer was topped up when it happens?

    "A full buffer causes other problems with certain printers and settings, including retractions. We’ve instead provided a speed variable that can slow your printer down when a splice is created. This is included in the latest CANVAS Hub plugin update."

    Of course it should not fill the buffer 100% It should fill it to the maximum safe level. Neither which is possible because it lack the needed hardware to detect that the buffer is reaching the maximum safe level. Terribly sorry that I did not always say maximum safe level. Normal people would understand it, but I should have realized a long time ago that this is not normal.

    Slowing down is nice, but to little to late for this thread. Blindly slowing down the print is a lot better than the previous solution of letting it smack into the brick-wall at full speed, but still a horribly disappointing solution. It should have had proper printer control from day one with adaptive control of the printer based on actual individual splice lengths. You did not advertise this as a beta program, you sold it as a finished product. And that is really far from the truth.

    "Concerning the buffer size, I think it’s obvious that increasing the buffer size (and therefore overall physical size of Palette) would allow for faster speeds. If the buffer allowed for 1 meter of filament, then you could print at the speeds that you’re suggesting. Our goal is to provide a compact solution that can be easily attached to a 3D printer. Based on the physical constraints of Palette’s hardware, increasing the buffer from 100 mm to 120 mm would not lead to faster printing. If your suggestion is to create a physically larger Palette in order to cater to higher speeds, we would respectfully disagree and suggest that the smaller size and lower cost are more important to a large majority of our users."

    So now you are saying that? I thought your engineers had conducted tests that proved that it did not affect the speed? What happened to those?


    Making the buffer loop around the whole face of the palette would hardly have made it any bigger at all, and would have solved all buffer problems.

    And what is your point really? That making the buffer big enough was to hard, so a decision was made to ship it with a to small buffer anyway, and make up some story about 8cm minimum segment lengths and how it would not help making the buffer bigger? Look over there!!! What? Why? I saw a bird! I swear!


    "I’m not aware of a call out to stop working on CANVAS, and it does have a major impact on enabling Palette 2 to print in multiple colors and materials."

    What an incredible stupid thing to say. There is more than adequate tools out there already for doing that job. Both they and CANVAS are worthless as long as the P2 is not working though.

    "Concerning the third-party open source software, this is being developed in conjunction with our team and support of Palette users. We’re happy to continue supporting our users who are actively trying to improve on resources we’ve provided."

    The point is that this software provided functionality that should have been on a point BEFORE "* launch" on your list of things to do.

    "Once again, our engineers and entire team dedicate their time and livelihood to Palette and the entire suite of Mosaic products. I do not appreciate insults to their hard work in and commitment to creating an innovative solution for multi-color/material printing."

    I keep wondering if the engineers really are as incompetent as your are making them look. Or if you are just throwing them under the bus to cover up for some marketing force in the company having oversold the product. The way it looks from the outside they do look incredibly incompetent though.

    "Returning to the original issue of this forum post, we are aware of the issue in Multi-spool and Random mode and expect to have a firmware fix available. If you require any clarification on any of the points above, please feel free to e-mail me directly at jonny@mosaicmfg.com or we can schedule a phone or video call."

    You are really not getting the point are you?

    1
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Thanks for your feedback, Kurt.

    0
    Comment actions Permalink
  • Avatar
    Kurt Skauen

    "Thanks for your feedback, Kurt."

     

    Your welcome. When will you answer the questions in my reply?

    1
    Comment actions Permalink
  • Avatar
    Jonny Yeu

    Hi Kurt, I've provided responses to your questions in my previous responses, but if you would like to discuss them further, I would be happy to jump on a video or phone call with you. If you'd like to provide your number over e-mail, I'd be happy to call you so that there are no additional fees incurred. We would like to ensure that we're on the same page, and sometimes information and intention can be lost over text. 

    I also wanted to reiterate that we've just released a Palette plugin update (http://mm3d.co/canvashub-plugin) that contains the ability to slow down the printer when Palette is creating splices. This is based off of a community plugin that was created on our Facebook group (https://www.facebook.com/groups/mosaic.users/permalink/324923731477535/). This will allow you to print at higher speeds without causing any issues with the buffer. Although this was not something we developed before the launch, we've received feedback about these issues and have provided updates for users.

    0
    Comment actions Permalink

Please sign in to leave a comment.