New experimental firmware 0.96c and web interface 1.07 November 09, 2014 10:31AM |
Registered: 10 years ago Posts: 665 |
Quote
Updated Arduino toolkit to 1.5.8 (patches can be found in ArduinoCorePatches)
- Merged in more of RRP's dev firmware 0.94 to be able to build the firmware again (thanks Adrian)
Code queue items are allocated on start-up, dynamic allocation is no longer used in my firmware fork
Removed some redundant code (Platform:etZProbing, HEAD_OFFSETS)
Code checks for code queueing improved and added proper description for design principles
M0 only turns off all drives and heaters if the print is NOT paused, although current tool is deselected at all times
GCodes: Replaced Platform::Message calls with reply.copy where applicable
Requirement to specify all the extruders for M92, M201, M203, M566 and M906 no longer exists
Implemented M500 (Store parameters in EEPROM) and M502 (Reset parameters)
Implemented M501 (Load parameters from EEPROM) with "S" parameter to enable auto-save (for backward compatibility)
Firmware can be built without Flash support; requires only one line to be commented out
PIDs return ABS_ZERO as current temperature if heater faults occur (web interface v1.07 will then display "error")
Vastly improved networking, increased both performance and available RAM (now I get 13k of free RAM)
Added Diagnostics call to Network class and moved all parameters to the Network header file
Fixed issue where "Skipping zombie request" was occasionally written to the serial interface
Bug fix: Old-fashioned G32 (without macro file) resets current bed compensation automatically
Bug fix: G4 waits for all moves to finish (only related to my fork)
Quote
Rearranged tables on the Control page:
- Quick commands are now displayed in a vertical button group and changed button order
- Extruder control moved below "Move Head Position"
Removed second slider for extrusion factor; users can now switch through each extruder by clicking on the label
Print progress is only updated if print start time is known
Panic buttons now write messages to the log
Moved "show OK" checkbox to the settings
Ability to upload jpg and jpeg files to the img directory
Vastly improved message log, last G-Code is logged along with its output
Print control sliders are disabled on disconnect
Many default values are displayed in the HTML file
Rearranged parameters on the Settings tab
Added glyphicons to a few buttons
Refresh button on the Gcode files tab is displayed in line with SD Upload Drop
Replaced target link of "get help here" with Ormerod forum
Added links to iamburny's, dc42's and my GitHub sites
If a heater fault occurs, "error" will be displayed in the head temperature cell
Minor bug fixes
Quote
reprap.htm
js/reprap.js
css/bootstrap-slider.min.css
css/main.css
Re: New experimental firmware 0.96c and web interface 1.07 November 10, 2014 04:04AM |
Registered: 13 years ago Posts: 1,611 |
Re: New experimental firmware 0.96c and web interface 1.07 November 10, 2014 05:12PM |
Registered: 10 years ago Posts: 209 |
Re: New experimental firmware 0.96c and web interface 1.07 November 10, 2014 06:23PM |
Registered: 10 years ago Posts: 665 |
Re: New experimental firmware 0.96c and web interface 1.07 November 11, 2014 07:11AM |
Registered: 10 years ago Posts: 209 |
Quote
zombiepantslol
Yes, you probably get a smaller binary because I build my firmware binaries with -O3 optimization enabled. Nice to hear it compiles well on different machines though, so thanks for your feedback!
I've been using Chrome to access my machine and I haven't had any problems resizing the web interface - may I ask which browser you're using? I intend to further improve the web interface for mobile devices, but IMO there were more important things to do first.
Re: New experimental firmware 0.96c and web interface 1.07 November 11, 2014 08:41AM |
Registered: 10 years ago Posts: 665 |
Quote
bobtidey
Compiled on Ubuntu 12.04, Eclipse Luna, Arduino 1.5.8 compiler.
Compiled with -O3 gives 249K so that is closer.
Quote
bobtidey
Non maximised but close in size. Now buttons go to the right and overlap, Graph goes wrong and extruder controls spill over.
Re: New experimental firmware 0.96c and web interface 1.07 November 11, 2014 11:54AM |
Registered: 10 years ago Posts: 209 |
Re: New experimental firmware 0.96c and web interface 1.07 November 11, 2014 05:39PM |
Registered: 10 years ago Posts: 780 |
Quote
bobtidey
One might be able to save a little bit of real estate in the layout whilst still keeping it a fixed size. E.g. the move control buttons are generously sized, and the extruder feeds could be relabelled as feed is a bit redundant. For the upper half either the graph could be shrunk a bit horizontally or the connect, stop, pause repositioned.
I might have a little go at seeing how much could be saved while still keeping it looking nice.
Re: New experimental firmware 0.96c and web interface 1.07 November 12, 2014 04:24AM |
Registered: 10 years ago Posts: 209 |
Quote
appjaws1
I always thought that the design of a web page should be able to accommodate most if not all screen sizes and that key fields would automatically adjust to accommodate the screen pixel count, this would include changing the font size etc. Perhaps I'm wrong, it has been a very long time since I had a dabble with web design.
Re: New experimental firmware 0.96c and web interface 1.07 November 12, 2014 09:51AM |
Registered: 10 years ago Posts: 780 |
Re: New experimental firmware 0.96c and web interface 1.07 November 12, 2014 01:04PM |
Registered: 10 years ago Posts: 665 |
Quote
appjaws1
I needed to stop a print so I pressed Pause and the print stopped but I could not raise the head, none of the controls worked.
...
I thought that if the Pause was pressed you should be able to move any of the axis and either resume the print or reset.
Quote
appjaws1
I then pressed reset and again nothing worked and all this time I had the hot end in contact with the print.
The only way I could move the Z axis was to switch off and on the ormerod.
Quote
appjaws1
You say in your release that Flash usage has become optional for my fork. Could you explain the pros and cons of using this please
Could this be the reason that I could not get any head movement after a pause? Do I really need to add M501 S1" to the beginning of my config.g file ?
Re: New experimental firmware 0.96c and web interface 1.07 November 12, 2014 07:12PM |
Registered: 10 years ago Posts: 780 |
Quote
zombiepantslol
bobtidey: I'm aiming to get the page scale down properly to 720px, but I need to touch the whole layout again to achieve this. My motivation for this change is my tablet, since I want to use it to monitor my prints sooner or later. I don't know when I get time for this again, but as I said, I want to implement it on a long-term view.
Quote
zombiepantslol
Yes Paul, this behaviour is intended, at least partially. The issue is when you pause a running print with my firmware fork, the movement will stop as soon as the current move finishes. But because the firmware doesn't know whether you want to resume your print or not, it doesn't allow any move-related codes to be executed as long as it's still paused. The reason for this is because it still has ~29 cached moves left to be executed at that time, and it's nearly impossible to "inject" another move at that state. At the moment this is the price to pay if you want to be able to pause the print almost instantly, but I want to improve it as soon as the Move code has become more "mature", i.e. when it provides smoother accelerations/decelerations, possibly a working bowden-tube elasticity compensation and refined drive stepping routines. Either way, this behaviour isn't new to my fork; in fact I changed the firmware to behave this way back in my 0.89 release.
.Quote
zombiepantslol
That sounds odd. I just tried to reproduce this problem, but without success. I paused a running print, pressed Pause, then Reset and my print stopped just as I expected. If this happens to you again, can you please post the output of M122 while it's paused and after you try to reset the print? That may help me figure out what went wrong on your machine.
Great explanation, now I understand I have added "M501 S1" to the beginning of my config.g file.Quote
zombiepantslol
The main reason Flash usage has become optional is because RRP wants their machines to start up in a neutral and identical state, which means all the settings should be set within the config.g file. I can understand this argument to some extend, because I wouldn't want to start troubleshooting end-user problems if I didn't exactly know what their actual configuration looks like. If some parameters (e.g. PID values) were modified earlier and saved to Flash-EEPROM, it can become quite difficult to find out why a machine isn't working the way it's supposed to. But this has absolutely nothing to do with the pause issue you mentioned. If you want to utilise Flash usage as known from dc42's or my older releases, you must add the command I mentioned to your config file. Otherwise your changes will be lost when you turn off your printer unless you set up those parameters anyway in your config.g file.
Re: New experimental firmware 0.96c and web interface 1.07 November 13, 2014 06:51AM |
Registered: 10 years ago Posts: 780 |
Quote
zombiepantslol
That sounds odd. I just tried to reproduce this problem, but without success. I paused a running print, pressed Pause, then Reset and my print stopped just as I expected. If this happens to you again, can you please post the output of M122 while it's paused and after you try to reset the print? That may help me figure out what went wrong on your machine.
Re: New experimental firmware 0.96c and web interface 1.07 November 13, 2014 07:10AM |
Registered: 10 years ago Posts: 780 |
Re: New experimental firmware 0.96c and web interface 1.07 November 13, 2014 12:14PM |
Registered: 10 years ago Posts: 665 |
Quote
appjaws1
What is the point of pausing a print if you can't do anything and the hwholeot end is in contact with and melting, the printed object ? I would have thought that as a minimum the hot end should be raised and then returned if the print is resumed. I know this would be difficult but could you not have an over-ride queue that would be actioned on the pressing of pause?
Quote
M122
Platform Diagnostics:
Memory usage:
Program static ram used: 47172
Dynamic ram used: 35068
Recycled dynamic ram: 3776
Current stack ram used: 1616
Maximum stack ram used: 3880
Never used ram: 8408
Last reset 00:00:34 ago, cause: power up
Last software reset code & available RAM: 0x0000, 13192
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
Longest block write time: 0.0ms
Slowest main loop (seconds): 0.011175; fastest: 0.000053
Move Diagnostics:
State: running
Heat Diagnostics:
Heater 1: I-accumulator = 0.0
GCodes Diagnostics:
Internal code queue is empty.
Network diagnostics:
Free connections: 15 of 16
Free transactions: 23 of 24
Free send buffers: 19 of 20
Webserver Diagnostics:
Re: New experimental firmware 0.96c and web interface 1.07 November 13, 2014 12:17PM |
Registered: 10 years ago Posts: 2,472 |
Quote
zombiepantslol
At the present time the whole purpose of the Pause button is to simply make movements stop, so you can either resume or reset the current print. I personally don't see any real advantages in allowing moves while a print is paused when using the current firmware, e.g. because the nozzle will start oozing very quickly. If it were possible to set up custom macro files to define exactly what should happen when a print is either being paused or resumed, we could define extra retractions (and feed moves, respectively), tool (de)selection and custom moves to be executed just-in-time. This may be implemented eventually in the firmware though, which is why I haven't replaced the Pause button with "Reset Print", but I won't change this behavior in my firmware fork until I see a good reason to do so.
Re: New experimental firmware 0.96c and web interface 1.07 November 13, 2014 12:25PM |
Registered: 10 years ago Posts: 665 |
Quote
dmould
One potential use of the pause button is to allow you to insert a captive nut that is going to be buried inside the part. In that case you may need to move the head out of the way, insert the nut and move the nozzle back before resuming.
Re: New experimental firmware 0.96c and web interface 1.07 November 13, 2014 12:39PM |
Registered: 10 years ago Posts: 780 |
Quote
zombiepantslol
At the present time the whole purpose of the Pause button is to simply make movements stop, so you can either resume or reset the current print. I personally don't see any real advantages in allowing moves while a print is paused when using the current firmware, e.g. because the nozzle will start oozing very quickly. If it were possible to set up custom macro files to define exactly what should happen when a print is either being paused or resumed, we could define extra retractions (and feed moves, respectively), tool (de)selection and custom moves to be executed just-in-time. This may be implemented eventually in the firmware though, which is why I haven't replaced the Pause button with "Reset Print", but I won't change this behavior in my firmware fork until I see a good reason to do so.
Quote
zombiepantslol
Regarding your diagnostics output: Sorry, but I can't see any M122 call in there :
Quote
zombiepantslol
Oh, and the heater code hasn't changed in my latest releases, so I suggest you increase your heater "S" value a bit. See dc42's 0.78e firmware release on how to adjust this particular parameter using M301. I bet dc42 could give you better advice on this, I must admit I'm not too familiar with PID controllers (yet).
Re: New experimental firmware 0.96c and web interface 1.07 November 13, 2014 05:35PM |
Registered: 10 years ago Posts: 14,672 |
Re: New experimental firmware 0.96c and web interface 1.07 November 14, 2014 01:13PM |
Registered: 10 years ago Posts: 2,472 |
Quote
zombiepantslol
Quote
dmould
One potential use of the pause button is to allow you to insert a captive nut that is going to be buried inside the part. In that case you may need to move the head out of the way, insert the nut and move the nozzle back before resuming.
Yes that's true, but when using my fork, moves will stop as soon as the current move has finished. Especially because you don't have to wait for the next ~29 moves to complete, I think it should be well possible to estimate when to pause the print to insert custom parts like nuts or so.
Re: New experimental firmware 0.96c and web interface 1.07 November 17, 2014 01:27AM |
Registered: 10 years ago Posts: 665 |
Re: New experimental firmware 0.96c and web interface 1.07 November 17, 2014 07:39AM |
Registered: 10 years ago Posts: 780 |
Quote
zombiepantslol
Paul, thanks for your report, I could reproduce the problem you are experiencing.
A quick status update: I've got the pause feature fully working with my latest changes, but I haven't finished paused/isolated moves yet. I intend to make M24 (Resume) go to the position where the print was interrupted, but this turns out to be more difficult than I expected. When I have everything working, I'll make the firmware run pause.g and resume.g when a print is either paused or resumed. I think this will improve quality when a paused print is resumed.
Re: New experimental firmware 0.96c and web interface 1.07 November 17, 2014 12:26PM |
Registered: 10 years ago Posts: 780 |