Please help us to test firmware 1.17RC3 and DWC 1.14
-
Yeah that what I checked but I made a screen shooting the heights I display before and after. The file is different but not the rendering…
-
Could it be that the browser has cached the old height map file?
-
Happy New Year!
I'm having a problem in DWC 1.14-b4 with Webcam Integration. The working URL to acquire a snapshot from my cam is "http://192.168.1.128/webcapture.jpg?command=snap&channel=0". This URL works perfectly in Firefox, Chrome and IE. When I add this URL to the DWC interface, I am getting a dummy response appended to the end of the URL on the print status page, causing it to not display an image. As an example= "http://192.168.1.128/webcapture.jpg?command=snap&channel=0&dummy=0.3392961592542225". The dummy number changes every 5 seconds, and no image is displayed. It seems any "&…." placed after the end of the working URL causes the issue. Please take a look at the solution provided at this URL. https://github.com/Oitzu/pimatic-iframe/issues/8 -
The changing dummy= is to prevent your browser caching the image and just keep displaying an older version. It shouldn't stop the image from displaying. Do you see the image if you open that URL in its own tab?
-
The changing dummy= is to prevent your browser caching the image and just keep displaying an older version. It shouldn't stop the image from displaying. Do you see the image if you open that URL in its own tab?
I added this info in my post above….
It seems any "&…." placed after the end of the working URL causes the issue. Please take a look at the solution provided at this URL. https://github.com/Oitzu/pimatic-iframe/issues/8It appears they use a "?$variable" to update the URL and prevent the caching. So far, this does look like it works in a separate browser tab. But anytime I add the additional "&" to the URL, it fails with net::ERR_EMPTY_RESPONSE and no image is displayed in the DWC or in a separate browser tab.
-
Could it be that the browser has cached the old height map file?
I have no explanation… I tried to disable the cache. I tried a different browser... I have no reliable method to get the newly saved heightmap displayed without waiting a day...
I try to get a reproducible sequence to find the problem... didn't have much time these days... -
It appears they use a "?$variable" to update the URL and prevent the caching. So far, this does look like it works in a separate browser tab. But anytime I add the additional "&" to the URL, it fails with net::ERR_EMPTY_RESPONSE and no image is displayed in the DWC or in a separate browser tab.
Interesting. Seems the camera treats the second ? as if it were another query separator. I think we'd have to test that solution with other cameras as they may reject it as a non-standard URL.
As a matter of interest, what does your camera do if you use a semi-colon ; instead of the ampersand? Both & and ; are, in theory, valid data separators
-
It appears they use a "?$variable" to update the URL and prevent the caching. So far, this does look like it works in a separate browser tab. But anytime I add the additional "&" to the URL, it fails with net::ERR_EMPTY_RESPONSE and no image is displayed in the DWC or in a separate browser tab.
Interesting. Seems the camera treats the second ? as if it were another query separator. I think we'd have to test that solution with other cameras as they may reject it as a non-standard URL.
As a matter of interest, what does your camera do if you use a semi-colon ; instead of the ampersand? Both & and ; are, in theory, valid data separators
I tried many different characters (;:"?[{}]) after the working URL of "http://192.168.1.128/webcapture.jpg?command=snap&channel=0" and any character other than "&" is ignored and allows the image to populate. As soon as I add a "&", it fails with the "ERR_EMPTY_RESPONSE" in both DWC and in browser windows.
-
I've been testing RC3 and, to be fair, I haven't tried pause resume since verson 1.15 so this may not be unique to 1.17RC3. However, now I've built myself a filament sensor so I'm cleaning out the ridiculous number of old rolls of material that I have and I'm getting some odd behavior.
When I suspend, the system does what it's supposed to raises 5mm and moves the head to the front of the bed at a sane speed. When I resume, however, the head returns to position at a speed that may actually be above the maximum speed set in my file. I halved the speed in M203 for X,Y,Z from 30000 (500mm/sec) to 15000 (250mm/sec) and the speed of the resume didn't seem to change.
Really, the maximum speed shouldn't be an issue anyway, right? It should follow the F command in my resume macro. Here is my resume macro:
; Resume macro file
G1 R1 Z2 F2000 ; move to 2mm above resume point
G1 R1 ; lower nozzle to resume point
M83 ; relative extruder moves
G1 E4 F2500 ; undo the retractionAm I doing something wrong?
-
The resume move should take place at 2000mm/min as specified in your G1 command.
-
The resume move should take place at 2000mm/min as specified in your G1 command.
I also tested with 1.17 release and this is the result:
If it would help, I can download the config. Unfortunately, the newest 1.14-b4 of the web interface opens the files rather than downloads them when you press the download button.
What can I provide to help narrow this down?
-
I've been testing RC3 and, to be fair, I haven't tried pause resume since verson 1.15 so this may not be unique to 1.17RC3. However, now I've built myself a filament sensor so I'm cleaning out the ridiculous number of old rolls of material that I have and I'm getting some odd behavior.
When I suspend, the system does what it's supposed to raises 5mm and moves the head to the front of the bed at a sane speed. When I resume, however, the head returns to position at a speed that may actually be above the maximum speed set in my file. I halved the speed in M203 for X,Y,Z from 30000 (500mm/sec) to 15000 (250mm/sec) and the speed of the resume didn't seem to change.
Really, the maximum speed shouldn't be an issue anyway, right? It should follow the F command in my resume macro. Here is my resume macro:
; Resume macro file
G1 R1 Z2 F2000 ; move to 2mm above resume point
G1 R1 ; lower nozzle to resume point
M83 ; relative extruder moves
G1 E4 F2500 ; undo the retractionAm I doing something wrong?
I think I found the problem. The F parameter is not processed correctly on a G1 command with the R parameter. I will fix it in 1.17a. Meanwhile, try the following in resume.g:
; Resume macro file
G1 F2000 ; set feed rate
G1 R1 Z2 ; move to 2mm above resume point
G1 R1 ; lower nozzle to resume point
M83 ; relative extruder moves
G1 E4 F2500 ; undo the retraction -
the macro I provided was enclosed by M120 & M121. I read RRP does add them, no need to write them in the macro.
So it's all my fault
(it wasn't complaining about that with 1.16 but hey it's now ok)I found the problem. If M120 succeeds then execution of the current file stops. So it never gets to do the M121 and after running the macro a few times, the stack for that input channel reaches its maximum depth of 5. Will be fixed in next release.
only thing left is: a macro named Z-0.01 in the macro editor (dwc) appears as Z-0 in the machine control tab. (ultra minor bug)
Yes, I see that too. I'll alert chrishamm to it.
Ace, Thanks to you both.
Happy new year ! -
Apart from being very happy about the release, mesh probing, polished PID tuning and stuff I have two things I do not necessarily get.
One is that M83 in config.g does not work, I put M83 in every g-code even in pause.g.
The second is that the printer is dead after engaging head or bed warmup, until it gets required temp.I'm sure this is one of my silly overlooks but anyway what are the new inner workings of these?
-
Apart from being very happy about the release, mesh probing, polished PID tuning and stuff I have two things I do not necessarily get.
One is that M83 in config.g does not work, I put M83 in every g-code even in pause.g.That is listed as a known issue at https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW. It is fixed in 1.17a which I hope to release by the end of this week.
The second is that the printer is dead after engaging head or bed warmup, until it gets required temp.
If you use the old gcode commands M109 and M190 to set the temperatures and wait, that's normal behaviour for any firmware because of how those gcodes are defined. Although with the 1.17 release, you should be able to execute commands from other input channels concurrently with M109/M190 until there is a resource clash between the commands.
If you select a tool and you have both movement and wait-for-temperature commands in the tool change files, then movement will be frozen until the tool change macro completes. You can avoid this by putting the movement commands in tfree and tpre, and the wait-for-temperature commands in tpost.
-
This was without starting g-code only after hitting tool button (setting it to active state) on DWC or PanelDue.
It's strange because once it worked wrong, then ok. I must have messed something then.I have nothing in tool selection macros, but as we are here I have another question.
In KISSlicer (and others only we use K. extensively) there are custom g-codes for prefix, select new tool, cool and retire, postfix etc.
I understand the correct behaviour is not to use slicer custom g-codes for selecting/deselecting tools, only new macros tfree, tpre?
So in KISSlicer It would be only useful to make prefix (eg.T0, M116 P0, M140 S70) and postfix (eg. T-1, M140 S0) and don't use tool selection g-codes at all, just macros? -
This was without starting g-code only after hitting tool button (setting it to active state) on DWC or PanelDue.
It's strange because once it worked wrong, then ok. I must have messed something then.I just tested it selecting a tool on PanelDue and I was able to move the print head around while it was heating up. Let me know if it happens again and you manage to reproduce it.
I have nothing in tool selection macros, but as we are here I have another question.
In KISSlicer (and others only we use K. extensively) there are custom g-codes for prefix, select new tool, cool and retire, postfix etc.
I understand the correct behaviour is not to use slicer custom g-codes for selecting/deselecting tools, only new macros tfree, tpre?
So in KISSlicer It would be only useful to make prefix (eg.T0, M116 P0, M140 S70) and postfix (eg. T-1, M140 S0) and don't use tool selection g-codes at all, just macros?You can use tool selection macros in KISSlicer if you wish, but IMO it makes more sense just to have it generate tool selection commands (T0, T1 etc.) and use the tool change macros that RepRapFirmware supports.
-
After a restart it works ok, I hit heater 1, it starts heating up, then home all and it homes while heating.
But when I pause and cancel printing a file and then after the cancel hit heater 1, it starts heating up and waits until it's ready.Said g-code starts with :
G21 G90 M83 T0 M116 P0And I have no magic in pause gcode also, just move up and to the center and retract a bit.
As far as I remember there was no such behaviour in 1.16
Perhaps it would be best to update to your todays version and check.
