Nothing getting analysed #247
Comments
|
@eyal0 any info on this? |
|
I do see errors in your logs that shouldn't happen: recent call last): That's surprising. It looks like the file was analyzed yet the output from that analysis wasn't valid and it couldn't understand it. Are you able to connect to your device that is running OctoPrint (maybe it's a Raspberry Pi) and try running the command yourself? Just type in: And see what happens. Thanks. |
|
I get the following error: |
|
The input to the above line = ' {"estimatedPrintTime": 144989.22102009310037829, "printingArea": {"maxX": -inf, "maxY": -inf, "maxZ": -inf, "minX": inf, "minY": inf, "minZ": inf}, "dimensions": {"width": -inf, "depth": -inf, "height": -inf}, "filament": {}}\n'I tested exactly where it breaks and Also based on the above output I can see that there is an estimate (idk what unit that is), not sure if it somewhat matches wth the actual print time I had on that piece, it took |
|
Okay, the infs are bad, yes, that means infinity! The time is in seconds. 144989.22102009310037829 seconds is about 40 hours, which is similar to what you experienced, yes? So not bad. The cause for the infinities is usually due to some problem with the processing. I will give you a new command to try: The python command that you ran before is running this Notice that the command is multiple lines! This is expected and good. Each of those M code commands should be on a different line so that it is processed correctly. Please try and let me know what the output is, thank you! I will show you what my output looks like, so that you can see an example: I have removed some of the lines that are in the middle. My estimate was 148433 seconds. Notice, no Please try and send the output. You can remove some of the lines in the middle, like I did, so that it is not too long. |
|
The output was really long so I did here is the output here is the original output if you need that yeah seems like the output of marlin-calc is no good. Does this binary have a more verbose mode? I was thinking if this works for you and not for me it could be different input. So I went ahead and downloaded what I uploaded when I opened the issue (btw i just downloaded taht from the octoprin interface). I also got the one I have been using for all the test (the one that in the uploads folder in the pi, the one that fails) and compared the MD5 sum hashes and they don't match. So I |
|
The binary does not have a more verbose option, no. I've never seen this kind of failure. It's surprising to me that it should fail like this. I would expect that it either fails entirely or provides the correct answer. Somehow for you it is computing the total time correctly but all the rest is wrong. Very odd. There are many versions of marlin-calc in the same directory, each one is for a different platform. Can you see if one of the others is working better for you? PTG was supposed to guess the correct one but maybe that didn't work? By the way, what is the hardware for your OctoPrint? It's a regular Raspberry Pi? If you know how to compile code, the source code for marlin-calc is on GitHub and it's eyal0/Marlin. You need to find the SConstruct directory in there and run I really can't think what might be causing the issue that you are seeing. Maybe it is the floating point math? In the code we are trying to find the maximum value for each coordinate x y z. The maximum of negative infinity and some number should be the number so the infinity should disappear. Perhaps also trying running marlin calc without any of the M codes. You can provide an empty string or you can just leave it out and process the file with defaults. See if that is different. Also, my time estimate is not the same as yours. That's unexpected. It should be identical. You're using the latest version of PTG? |
|
Its up to date with the lastest from the octoprint repo. that is yeah I am running octoprint from my pi. so arm yes. Also I tried with the gcode file path argument for the same file and with an empty mcode argument and got the following: Ill compile that when I free up so I can mess around with the source. Can you roughly point me to the source file that you think may be causing the issue? if not ill figure out once I compile it. |
|
Ah this one looks better! No infinity! |
|
Try to use just some of the M codes and determine which one is causing the infinity. |
|
I tried the same file with each M code separately. here is a list of the ones that passed or failed: one very interesting output that may help you narrow down the bug, here is the here is the and note the middle value, in the event that it works then it is not zero very early on the processing. if contains one of the failing Mcodes ( listed above) then it is zeroed out for the whole analysis. I assume this is related to the math behind the program, once it fails it fails and just keeps being zero. Just curious, is my assumption that the extra mcode argument is prepended to the file before analysis? I have also further tested the failing code the syntax for M221 is |
|
Good analysis. Yes, it's true that the M codes are prepending. It's the same as if the M codes were at the top of the file except that putting them into the file would affect the line numbers and file size so they are ignored for that. S0 means to print with a rate of 0% so that will definitely affect the print! I added something about this in the wiki. Click on wiki above and read the page of common problems. It mentions how you can type M503 into your printer and see what the correct values are. You can also find them in the directory .octoprint... I forget the name of the file and I am not next to the computer but it will have the m codes in there. When you type M503 on your printer, PTG will learn the latest values. |
|
Will give that a try once a print finished and I can connect the octopi once again. Probably tonight. If I recall correctly that was one of my first troubleshooting moves, but Ill give it a try again. Ill post again once I execute that. As a side note: Also thanks for the help, really appreciate it :) |
|
I had that thought once but somehow I thought that it would be difficult to do. Not sure why. Common problem, though. I should think of a solution. |
|
Just very curious, why does PTG have to prepend code? |
|
So I issued teh M503 command and waited around a minute or so, then checked Here is the output from the terminal for the 503 command: After comparing the config with the printer_config file I realized that there is no M221 or flow rate on the M503 output. Therefore PTG cant grab it. I have also looked into the marlin gcode/mcodes and apparently, you can't get that? Should the M503 include the output for M221 by default? As a temporary solution I went ahead and changed Perhaps my issues started to happened way earlier and did not manifest until later. I originally had the original ender 3 motherboards. then changed that for the SKR Mini E3 V2.0. I installed the manufacturers Marling firmware in it. So far no issues here as everything was still configured the same(no config change yet). Then sometime later I got a BLtouch. At this point I issued the M503 command to configure it, as well as linear advance, only that this time I assume this firmware does not have the M221 in the output for M503. I assume that when PTG does not detect the flowrate it automatically sets it to 0 in printer_config file. This could be a bug? as it should leave the lines of the config alone if it cant find information realting that line? (again I am assuming that it modifies all the config upon receiving a M503) Anyways, we can see here that the exact lines that the code searches for are not in any output(as this is a hook for any output), therefore its never going to get it. A more new user-friendly solution would be to default the config to a flowrate of 100%. I don't know what piece of code initializes that but that would be a quick fix if you feel like that would be a smart change. Let me know, if I have time I may open a PR. As for me, I am satisfied with the solution I have. I have learned a lot about this codebase troubleshooting this problem, Once again thanks for the help. If you have no more comments you can close it. |
|
The default for the flow rate is 100%. Not sure how the zero flow rate got into your saved config. There is a file printer_config.py which gets a copy of every Mcode that is either typed in by the user or appears in the output of M503. If it's the output of M503 then sometimes it has some processing done, like the removal of the "echo: " at the beginning. And as you noticed, recognizing the word "Flow:". All this is done to deal with the various ways that printers show the M503 output because that is, sadly, not standard. The printer_config.py has no defaults. It only stores a specific list of M codes, not all of them. If a new Mcode is seen that matches the list of Mcodea that we care about then the old one is replaced by the new one. The list of Mcodes is never cleared. Only when a new one arrives, sometimes an old one is replaced. The default is no Mcodes at all in which case the defaults come from marlin-calc, which has the same defaults as the Marlin software itself (because they are the same code). So either PTG screwed up and thinks that it saw a flow rate of zero when it didn't, or at some point there was a flow rate of zero and then it disappeared. Because your M503 didn't include a flow rate, the bad flow rate was never removed. Maybe it would be good if PTG could recognize the M503 command and clear out all the saved printer_config.py before interpreting all the following "echo:" lines that are about to refresh the config? |
|
Here is a quick fix: # in the PTG class add the following
#class PrintTimeGeniusPlugin:
def clear_printer_config(self):
self._old_printer_config = self._current_config.as_list()
# the new item never touches the file, taht is done by the on_startup hook
self._current_config = PrinterConfig() # so this is empty config
self.write_printer_config()
# cahnge hook
def command_sent_hook(self, comm_instance, phase, cmd, cmd_type, gcode, subcode=None, tags=None, *args, **kwargs):
if self._printer.is_printing():
return
strip_cmd = cmd
strip_cmd = strip_cmd.strip()
# not sure if this is what this hook does, octoprint has no documentation on the sent hook
# I assume this is right?
if "M503" in strip_cmd.upper():
self.clear_printer_config()
self.update_printer_config(strip_cmd)If you like it I can put a PR |
|
That looks pretty good. I don't have a way to test it because I don't own a printer. If you make the PR, can you test it? You could open up the file Also, some people like to have flow rate so you might test with setting flow rate to, say, 90%, and then see that it is correctly in the printer config after you type M503. If you write that PR, I will review it and release a new version, yes. |
|
Cool yeah, I can test it. I am currently traveling I won't get this done till Monday, Tuesday. correct me if I am wrong when you say
can you elaborate more on this
|
|
Right, all of that. So like this: Patch the code, then do this:
Then do this:
That would be the most thorough way to do it. I suggested stopping OctoPrint before checking the file because I think that the file is only written after OctoPrint is closed, not during operation. This is needed so that we don't write to the file over and over again, which really slows things down. That would be the most thorough test. I would test it myself but for that, I would need a printer with Marlin installed that can respond to Thanks for helping! No hurry, whenever you're able is great! |
|
As a side note to your printer problem. octoprint has a virtual printer, not sure how useful this could be to you. |
|
Yes, I've used it! One of the limitations is that it doesn't do Hmm, I wonder if OctoPrint would want a more accurate simulation there. I could make a Marlin virtual printer that works off real Marlin code... Interesting. Would be a cute project. |
OctoPrint Version:
OctoPrint 1.5.3 Python 2.7.16 OctoPi 0.17.0PrintTimeGenius Version (if you know):
2.2.7Cura:
4.8.0What did you try:
Checked my config (M503). Checked that the commands M201, 202 .... dont have S0 in them (in my gcodes). I also checked issues here in github for similar errors but didnt find one.
What happened:
Everything was working perfectly. One random day it stopped analyzing, this did not occur after an update.
None of my files are getting analyzed
What did you expect to happen:
Analyze a file
Here are two logs. One is after a reboot if that makes a difference.
plugin_PrintTimeGenius_engine (1).log
plugin_PrintTimeGenius_engine.log
here are two sample gcodes that will not work:
sample_gcode.zip
The text was updated successfully, but these errors were encountered: