Won't print

A6y_N0rma1
Posts: 37
Joined: Thu Aug 03, 2017 5:25 pm

Won't print

Postby A6y_N0rma1 » Fri Jun 26, 2020 7:42 pm

This is a weird one for me. I've been printing for awhile and all was good in 3D N2 land. Today, I noticed that the left nozzle was not purging before a print. I unloaded and reloaded the filament, but no luck. I have a mark on the stepper shaft so I can see if it's turning (it is). Even after a successful filament load (Raise3D PLA @ 225), it refuses to purge although the stepper seems to be turning slowly. I then decided to switch the filament over to the right nozzle. Same thing. Successful load, but no purge before print or during print. I even disassembled the Bondtech extruder to make sure all was well and probed the nozzles with a 0.4mm nozzle cleaning needle.

The only thing that has changed is that I upgraded RaiseTouch to 1.4.1.529 with RaiseCloud. The whole nozzle purge actions seem faster, less time trying to purge, and then almost immediately to printing without the slooow movement to the right before positioning the head to print. I'm out of ideas guys. Any suggestions that I missed?

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Fri Jun 26, 2020 8:48 pm

What could change under a raistouch update?

A KEY ONE- being steps per mm. In other words, one of the KEY things over time added was that instead of updating motion control firmware with hard coded values to match possibly upgraded hardware like oh say a Bondtech extruder that REQUIRED the user to either invoke custom motion control firmware, or later, after this feature was often requested and raise began selling the Bondtech as an option, then the raise touch application had the setting for the steps per mm and how that works is on boot up it sends he standard gcode commands to the motion board to override the default steps per mm in firmware . In other words, let's say you date or somehow the update process forgets the non default steps per mm REQUIRED for Bondtech upgrade operation, then your motion control firmware just keeps the non upgrade built in default and low and behold you complain your printer doesn't work.
And it won't...
Why? Because the Bondtech needs 415 steps per mm, and default was if I remember 96, so more than 4 times less filament is being fed than commanded. AKA holy crap under extrusion or looking like it's not extruding.

Again simple answer,
You are running a non stock printer.
There are certain settings you need to properly adjust for your hardware upgrades.
That setting is stored in the Raisetouch application (hardware settings, steps per mm) and entirely possible an update somehow defaults back to 96 from the required 415 for that hardware.

A6y_N0rma1
Posts: 37
Joined: Thu Aug 03, 2017 5:25 pm

Re: Won't print

Postby A6y_N0rma1 » Fri Jun 26, 2020 9:18 pm

Jeyguy, I thought of that and checked to see what the setting was. Is was still set correctly for 415 as required for the Bondtech. Another thing i noticed is that at the beginning of a print, the dwell time for the purge seems much shorter and the slow move to the positive X position is essentially gone. In IM, the start GCode still has G1 F140 E29 and G1 X20 Y0 F140 E30 which I believe is the purge and slow right movement?

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Fri Jun 26, 2020 9:39 pm

All about context.
Yes, that line is an XY move and an extrusion line.
It's important specifically on that line to know and see th previous couple of lines because it affects how that line is executed.
On just face value, you are extruding 30mm of filament while moving to target position X20 at feed rate of incredibly slow F140
But, not shown, before that line, the extruder is in absolute mode!!!
So it went from 0 to 29 on the first line and fed 29mm of filament.
And then on the second line, it moved 30-29=1mm of filament.

Let's put some other things into context too.
you saying this, "the dwell time for the purge seems much shorter and the slow move to the positive X position is essentially gone", while might be what you are observing, in terms of what really happens is not correct.
What I'm trying to get you to know is there is no time here.
Gcode is distances and speeds.
Speed, being distance over time, could be construed or observed as time to complete a task, but what I'm trying to get you to see is that the gcode is DISTANCES ONLY. Not time.
So, if we observe time to be short to complete a task, either distance is WAAAAAAAY off, or Speed- AKA Feed rate, is waaaaaaaay off.
But, you also said, you see the motor moving slowly- context, around trying to feed filament- so slowly compared to previous, and slow is less distance over time, and less distance being the worrying part.

So, the 2 variables in question- distance- specially the extruder is affected by flow rate.
Flow rate literally tells the firmware to read that good E distance and multiple it times the flow rate value as a percentage.
100% = distance commanded is distance executed.
Less than 100% less distance executed.
Greater than 100% more distance executed.

The OTHER factor is feed rate.
Feed rate simply takes whatever the default speed in F value is and the same way, multiplies it times the percentage,
F values are in mm/minute.-Very important to know.
Hence why I said, F140 is damn slow. 140mm over 60 seconds.
Or take the 20mm distance @140mm/m takes roughly 8.6 seconds- hence yeah, that would look slow.
And, the subsequent next not shown line of gcode unless it has a feed rate F value in it, reuses the previous lines value hence even the next move possibly being run that slow (140mm/minute). Again, that pesky context thing where a single line of gcode cannot always be taken at face value, lines before it can set modes and defaults that change how a line is executed.

So if the printer isn't executing that line (as you think it should or did previously), my second guess (if not steps per mm error) is either feed rate or flow rate, and since you are having extrusion issues aka distance issues, probably flow rate is my best guess is not 100% resulting in massive under extrusion you are seeing as lack of prime and extrusion.
Last edited by Jetguy on Fri Jun 26, 2020 10:21 pm, edited 2 times in total.

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Fri Jun 26, 2020 9:49 pm

Again, in a nutshell.
At the hardware and firmware level we have a few relationships.
Steps per mm has to match the hardware so the hardware is commanded to go the correct distance.
Going the correct distance is both important for distance and since speed is distance over time, if distance is wrong, so is speed.

Then 2 values affect how firmware at a fundamental level executes gcode.
Flow rate make the firmware execute something more or less distance than commanded for E only (doesn't affect any other axis).
Feed rate changes how the firmware executes feed rates in gcode. Basically again, either faster or slower, but by a percentage.
Feed rate just makes things slower or faster, but on "face value' doesn't change distances.
That said, extremes of speed can cause hitting hardware limitations, like pushing a stepper too fast to skipping steps, and then we do lose distance in that instance.

You changed the raise touch which is just the gcode streaming side of this.
It could have any of the above faults
Incorrect steps per mm
Incorrect flow rate
Incorrect feed rate

That said, it doesn't go in and change print files line by line changing gcode.

Just trying to help pinpoint what does what and what could happen.
Last edited by Jetguy on Fri Jun 26, 2020 10:14 pm, edited 1 time in total.

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Fri Jun 26, 2020 9:53 pm

Also, on the N series, this is why I keep harping, good to have that reprap discount full graphic LCD plugged into the motion board.
We can perform a LOT more direct diagnostics like see what the motion board actually says is happening VS what the touchscreen sent.
Like check actual step per mm, actually command direct extrusion from motion control without sending gcode and so forth.
Gives you direct insight into exactly what the motion board is seeing and doing.

Either it's this computer and web browser or something, but auto mistake seems in full effect today. Sorry for the typos.

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Fri Jun 26, 2020 10:24 pm

And I could be wrong on all of this, it's some hardware bug or some weird raisetouch version bug I hadn't before seen.
Just going on the info and experience and knowledge I have in front of me.

I guess the obvious.
Test
Use the control panel, preheat the extruder and then command 10mm of filament and measure what it actually fed in.
If 10mm, then steps per mm and flowrate at that moment are correct.

A6y_N0rma1
Posts: 37
Joined: Thu Aug 03, 2017 5:25 pm

Re: Won't print

Postby A6y_N0rma1 » Fri Jun 26, 2020 11:36 pm

Jetguy, thanks for all the info. I know you are trying to help. I have read many of your posts in the past and you certainly know more than I.

However, I don't consider my system to be "non-standard". It's a N2 upgraded with the Bondtech extruder sold by Raise3D. I use IM for my slicer, and all of the Gccode listed under the Gcode tab in the slicer has never been altered, it's what comes with the IM install. The fact that this all happened after upgrading RaiseTouch to 1.4.1 could just be a coincidence. BTW, the MCB firmware is 1.1.6.

You are correct that gcode is all speeds and feeds, and the two lines of code are what was in IM (which was also upgraded to the latest version). Like you said, a movement of a specific distance at a specific rate does equate to time. My confusion is why this is not happening like it was to prior to the upgrades. I never looked at the startup gcode in the past, so I just presuming that it's the same.

You mention the display in another post, so I'm bitting the bullet and will get the RepRap Full Graphic Smart LCD Controller - I believe that is what you were referring to?

I will continue to try to figure out what happened.

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Sat Jun 27, 2020 12:48 am

I know you may not consider it non standard, but it is.
It doesn't work correctly without user intervention.
In other words, if you replaced your screen box tomorrow and did nothing, your printer with a bondtech will under extrude by more than 4X.
Again the software baseline, the firmware, everything about that printer is configured by default for the OLD extruder.
Yes, Raise sold the upgrades, yes, you might even buy one already upgraded, but know that again, from day one, it requires configuration to match the upgrade.
Yes, in theory, you have the correct steps per mm per what you answered.
So, million dollar question, did you perform the extrusion test and verify via the control panel you actually extrude 10mm of filament when commanding 10mm of filament.
That goes a long way to solving this.

User avatar
Vicky@Raise3D
Posts: 6737
Joined: Fri Mar 25, 2016 3:54 am

Re: Won't print

Postby Vicky@Raise3D » Sat Jun 27, 2020 4:32 am

Would you like to recreate the issue on your printer again and export log files after you see the issue happens and share with us? Any video or picture can show the issue will be very helpful too.
We are not sure what is causing the issue. Once having the log file exported, please try roll back to older version and see whether the issue is still there or not.

A6y_N0rma1
Posts: 37
Joined: Thu Aug 03, 2017 5:25 pm

Re: Won't print

Postby A6y_N0rma1 » Sat Jun 27, 2020 2:50 pm

I did an extrusion test with the RaiseTouch at 1.4.1.529. I commanded 100 mm and only received 22.5 mm. I then downgraded to 1.2.1.428 and got the full 100 mm. Upgrading back to 1.4.1.529 brought the problem back, asked for 50 mm, got 11 mm.

I went back to 1.2.1 but a print of the 20 mm calibration cube had no nozzle prime at the beginning of the print. This was done with IM 3.6.0 Beta, so I downgraded it back to 3.5.3. Resliced and sent the cube to the N2 and it printed like a champ with the normal nozzle prime I had before. My N2 is back and running like a champ.

Through out this whole ordeal, the MCB stayed at 1.1.6-Rev1. Attached is the serial log file that I saved at the beginning, before and firmware changes. Hope this helps.
Attachments
all-raisetouch-875-20200627084442.tar
(1017 KiB) Downloaded 7 times

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Sat Jun 27, 2020 8:37 pm

Well, there it is, slapping us in the face.
In your log file #2 the M92 set axis steps per mm contains the WRONG values.
2020-05-26T18:00:51.887 EDT| raisetouch| serial: echo: M92 X80.00 Y80.00 Z800.00 E94.00
AKA the default values for the original NON bondtech extruder.

So what needs done and what I suspect the fix is, go into steps per mm in Raisetouch, change it if even by one value (416) and save, and then reset to 415 and save again.

Again, I found the offending line defaulting to the known incorrect extruder steps per mm given an upgraded bondtech printer.
Found in log file 3 too.
2020-06-21T19:40:43.388 EDT| raisetouch| serial: echo: M92 X80.00 Y80.00 Z800.00 E94.00

So my take, is something where the value or variable stored in a config file is displaying on the screen, but not actually being USED by raisetouch software application to properly send an M92 command at bootup with new updated values to the motion board.
Worse, M92 command was NOT found at all in log files 0,1, and 4.
So incorrect M92 was found in log files 2,3 only.
Attachments
4.log
(2.21 MiB) Downloaded 8 times
3.log
(2.28 MiB) Downloaded 7 times
2.log
(2.24 MiB) Downloaded 7 times
1.log
(2.03 MiB) Downloaded 7 times
0.log
(2.29 MiB) Downloaded 7 times

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Sat Jun 27, 2020 8:52 pm

What I'm trying to impress upon you as an owner, operator and maintainer/ troubleshooter of the machine is that again you have a non-standard "upgraded" printer that literally REQUIRES something, somehow, someway to change the default motion firmware steps per mm to the upgraded hardware setting matching your physical hardware.
Either Raisetouch has to send this on bootup
Or
Your custom hardcoded motion firmware made from source code is updated with specific steps per mm
OR
you ensure that every print file you make or slice and then print contains the M92 updated steps per mm with E415 matching your Bondtech every single time.

It's not entirely your fault an update stopped doing what it was previously doing- correctly sending your hardware config.
It is however, important to know and understand that that fact or requirement that it has to be sent.
How you choose to do it is a personal choice, but again, you have a single point of failure here- depending on the raisetouch to every single time correctly configure for the hardware you have. You could choose a more redundant method of ALSO ensuring your slicer profiles contain the updated steps per mm, thus ensuring via every print file, the machine is configured as part of the standard starting gcode.
Attachments
Printer settings home.jpg
Printer settings2.jpg

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Sat Jun 27, 2020 8:55 pm

Just want to make it clear, I am in no way defending Raise or raisetouch updates here. Clearly, proof something has gone very badly.
If one version works, then another doesn't, that's a problem.

I am saying, user awareness, knowing what you own and how it works, what it needs to work, are all very important things and not even something remotely told to you by Raise3D in the slightest.

A6y_N0rma1
Posts: 37
Joined: Thu Aug 03, 2017 5:25 pm

Re: Won't print

Postby A6y_N0rma1 » Sat Jun 27, 2020 9:43 pm

JetGuy, points well taken and another lesson learned.

I exported a sliced project and did a search of the Gcode with Notepad++. There is no M92 statement in the entire file. I presume that RaiseTouch is adding these commands prior to sending to the MCB. Just from looking at the code, one would not be aware that such a problem would exist. It never happened with the many previous firmware updates. I guess I was naive enough to believe that the settings shown by RaiseTouch (re Esteps value) were stored somewhere (EEPROM?) and it would read those values and not use some defaults. Hopefully, R3D (Vickey) will bring this to the attention of their programmers.

In IM 3.5.3, the Steps-E /mm defaults to 0 and I did not set this to 415 to get the printer working properly, so it must have gotten the correct value from RaiseTouch. When I upgraded to 3.6.0-Beta, I left it along as has always been the case (my mistake). I will consider adding the proper M92 code to my start Gcode to be safe.

I plan to slice the same small object with both IM 3.5.3 and IM 3.6.0-Beta and do a comparison of the Gcode to see what changes to understand more what is going on.

A6y_N0rma1
Posts: 37
Joined: Thu Aug 03, 2017 5:25 pm

Re: Won't print

Postby A6y_N0rma1 » Sat Jun 27, 2020 10:16 pm

I sliced a small washer in both IM 3.5.3 and 3.6.0B. There were no file differences when running a compare in Notepad++ nor were there any M92 commands in either of the two files. When I changed the default Steps-E / mm from the default value of 0 to 415 in printer setup, the output file now has a new M92 line with the correct value. The RaiseTouch evidently adds a M92 E94 command later if you leave it at the default value, ignoring any value you may have set previously in RaiseTouch.

Lesson, always set the correct value in IM and don't rely on RaiseTouch to set the correct value, even though it HAS the correct value.

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Sun Jun 28, 2020 2:29 am

A6y_N0rma1 wrote: the settings shown by RaiseTouch (re Esteps value) were stored somewhere (EEPROM?) and it would read those values and not use some defaults. Hopefully, R3D (Vickey) will bring this to the attention of their programmers.


No, EEPROM is not used in this printer. We are actually mixing these up.
First, EEPROM exists in the motion board processor mag 2560 chip, but is not enabled in the current versions of Marlin firmware as supplied by Raise. Flash memory is where the motion firmware is stored and inside that firmware are the default settings. When the mega2560 processor boots on the motion board, it boots the firmware and it loads into the active memory RAM of the mega2560 processor as the running program you know as firmware. Then the that program responds to gcode and stores variables also in RAM and thus why an M92 command can even change steps per mm. However, there is another command (M500) to then save non default updated values into EEPROM, and since EEPROM is not enabled as a function in the motion firmware, M500 does NOTHING. In short, every time the mega2560 on the motion board boots up using default steps per mm for the original non bondtech extruder.

The touchscreen pcDuino processor also uses a form of flash memory, in this case, eMMC, that more or less is a solid state hard drive with a controller and flash memory all on one chip. Again, it's effectively a hard drive. The operating system of the pcduino boots like a mini computer and the raise touch is a software application that is set to auto start shortly after booting. As a software application, it stores all the custom settings you save in a configuration file in a specific folder. Then the idea is that during the software Raisetouch update, part f that process reads the existing configuration file, uses it, possibly adds new settings and features added by that In other words, some insight into catch 22 how an update could go wrong. As features get added to raisetouch, the settings for those features have to be stored somewhere, and that somewhere is new items and values added into the Raisetouch config file. That file is growing and has more stuff, then it's entirely possible the format or name or some other change from an old file to a new file gets borked and you get he failure you just had happen.

So again, yes, absolutely something the developers should know and look at, something is definitely broken and you invoked it during the upgrade process with raisetouch updates. It's their problem to fix for sure. That said, user education and backup actions are also a good part of a comprehensive program. In other words, after an update, we ALL should be aware that non default values we may have stored might revert back. Again, that's a 2 part thing- knowing that you saved non default values and what that implies, and that they could be blown away with an update and need to be re-entered as a normal process of checks and things to do after an update of raise touch.
Last edited by Jetguy on Sun Jun 28, 2020 1:33 pm, edited 2 times in total.

Jetguy
Posts: 3082
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Won't print

Postby Jetguy » Sun Jun 28, 2020 2:39 am

A6y_N0rma1 wrote:Lesson, always set the correct value in IM and don't rely on RaiseTouch to set the correct value, even though it HAS the correct value.


No, this is also a bad incorrect lesson as you have written it.
You MUST properly ensure that raise touch is saving and using the steps per mm configuration for your installed hardware after any update.
Just looking at the setting is NOT enough as proven by this situation, we now may have to perform a test or look at log files to verify it's sending. As a process, to ENSURE it takes the updated setting, changing the values from default, then changing them again to desired values ENSURES the raise touch then saves and uses the new value. In other words, even if you update, and check and it says 415 steps per mm, you then change it to something OTHER than 415, save it, then go back, change it again back to 415 and save again and THEN it uses that value. Yes, a cumbersome process, but the best way I can come up with. For whatever reason, it's looking for a change in value before it assumes a change from default and even begins sending the M92 command. Sadly, I distinctly remember questioning about this kind of mistake happening when they first implemented this feature. Here we are a few years later with it biting us.
And you need this to happen correctly. You need the printer natively to correctly boot in the right config for the hardware you have installed.
Why?
Because if the raise touch doesn't set the correct steps per mm on boot up, then OTHER key functions of raistouch like the utilities screen for manual filament feeding, load and unload, and then also printing any previous file stored on the eMMC would not print correctly.

The lesson is, while saving the steps per mm in a slicing profile, is a good backup step, it doesn't solve all problems.
It ONLY can help ensure a brand new print file might print correctly.
It won't fix load and unload filament, it won't fix other problems, it's a good backup but not a primary fix.
The lesson is, do BOTH. #1 ensure after an update you don't assume anything. even if the update afterwards shows the setting, change the setting, save he setting, change the setting, save the final setting. yes, cumbersome, yes a pain in the neck, but I didn't write the software, I have to deal with it just like you. #2 Then also, as safety backup, it hurts nothing to also put something like the Bondtech steps per mm setting into the slicer too. It's not a catch all, but again, it would ensue that under a total worst case scenario, at least that newly created print file would print using the correct settings. Doing BOTH creates a layers of backup approach.
Last edited by Jetguy on Sun Jun 28, 2020 1:34 pm, edited 3 times in total.

A6y_N0rma1
Posts: 37
Joined: Thu Aug 03, 2017 5:25 pm

Re: Won't print

Postby A6y_N0rma1 » Sun Jun 28, 2020 1:17 pm

Well said.

User avatar
Vicky@Raise3D
Posts: 6737
Joined: Fri Mar 25, 2016 3:54 am

Re: Won't print

Postby Vicky@Raise3D » Mon Jun 29, 2020 5:59 pm

We found a bug in the latest firmware printing without the original motor on printer and got it fixed over the weekend.
If you'd like to help test the beta fixed version, please let me know. Or you can choose rollback to old version and see whether the issue is still there or not.


Return to “N Series”

Who is online

Users browsing this forum: No registered users and 1 guest