@dc42 Thanks
I have updated the firmware to 3.1.1
I am using rr_status to get the status object and will have to read the head temp (which I already have) and compare it with the requested temperature.
I accept that the machine will not execute commands until the temperature is reached but I don't want to send any commands to the machine via a web interface until the head is up to temperature.
I am running Duet Maestro with 3.01 RC12 firmware
I am monitoring the machine response object for the (I)dle situation.
Am I correct in believing that whilst the machine is waiting for the temperature to get to the set point the machine is still stating that it is (I)dle?
ie once M109 S260 is sent I still get (I)dle before that temperature is met
I know that I can monitor the current temperature and check against the requested temperature, but was checking to see if there was a status that told me that the machine was not up to temperature.
Thanks
Clive
@dc42 Thank you, fully understood and will solve the problem.
@chrishamm Thank you for the response, it will make life a lot easier
At present the only way to find out if there is space in the gcode buffer to send another command is by sending a rr_gcode command.
NetworkGCodeInput * const httpInput = reprap.GetGCodes().GetHTTPInput();
httpInput->Put(HttpMessage, GetKeyValue("gcode"));
response->printf("{\"buff\":%u}", httpInput->BufferSpaceLeft());
would it be possible to add the "buff" value into an existing rr_status or to create another one?
Would the buffer just be read and not otherwise be affected by
NetworkGCodeInput * const httpInput = reprap.GetGCodes().GetHTTPInput();
response->printf("{"buff":%u}", httpInput->BufferSpaceLeft());
I do not wish to move away from a standard build otherwise I would have a go at implementing the idea.
Thanks
@Danal Thanks for the ideas.
For the previous prototype, I used Marlin and the 8bit 1.4 Board and I took the suggestion to move to the Maestro board and had to do quite a bit to reconfigure everything (I don't regret the decision). I considered then offloading the calculations to an Arduino communicating over the serial ports.
When taking on the Maestro and finding it had a web interface over a network it seemed a good idea to me (I had used the ESP8266 to create other web based applications) and have invested a lot of time in this new interface.
I seem so close to a good working solution that I am pretty loathe to take another rework step.
It does work using a combination of the returned "buff" value and using the status flag, but is not as good as hoped.
I am sure that there must be a gcode that I can fire at the Maestro to return the buffer figure without consuming even more of it or that the rr_reply or rr_status could provide the figure as it appears to be essential for the efficient working of an external pre-processor.
Once again, thanks for your thoughts.
Following on the experiments, I did some timings (mS).
I have two HTTP streams, one a heartbeat every 300mS (The main Loop) and the other reserved for the main commands.
0: Sent to machine gcode=G0%20X150%20G0%20X300
1: Sent to machine gcode=G0%20X150%20G0%20X5
25: Answer OK = {"buff":241}
25: Request machine response
26: Answer OK = {"buff":239}
27: Request machine response
48: Answer response OK =
58: Answer response OK =
149: main Loop status=B (asynchronous to 0 point )
17859: main Loop status=I
As far as I can see, the machine does not go idle until the whole command line is processed and, in this case, all moves are completed.
In reality, I will not be sending the second set of gcodes until the answer back from the first.
So after sending the commands and the buffer being reduced, the only change I can detect is the status code 17 seconds after the first transmission.
Am I missing something?
I am monitoring the returned 'buff' value and sending concatenated gcodes to the Duet board when there is space.
I am also following this up with a rr_reply message immediately on getting a response back from the original rr_gcode message.
I am sending the codes faster than they are consumed so that the 'buff' figure runs down until it hits my safety low level, all seems fine. However, how does the 'buff' figure then recover?
Is there anything I can send which will not consume the buffer space but report back on it's value?
There is nothing in rr_status, rr_gcode or rr_reply that I can see will do the trick.
Software now v3.01 RC10 DWC 2.1.5
Thanks.
Thanks for the prompt reply.
I will rework the code now.
I am writing a javascript system to control bespoke probing and creation of print commands on the fly using the DWC interface.
This is all part of https://forum.duet3d.com/topic/15113/rotational-printer
I am running the Duet Maestro board and version 3.01 RC6 software
I can control the printer using rr_gcode and rr_status but I get long delays between command operation.
If I concatenate my commands together and send them as one, they perform perfectly.
I have tried two methods of control but using a javascript stack.
I can concatenate commands but would need to know how much space I have for this, I have assumed that it is the 'buff' response.
I could write a macro file or gcode file and upload it using rr_upload - I have not looked at how this works yet ie can it take a memory image, is there a files size limit.
Any suggestions would be welcome
@dc42 Yes, in config.g I have G31 X0 Y0 for now.
I am working on the physical calibration of the printer at the moment and will add these in when complete.
Thanks
@bearer Thanks for the reply.
I had started thinking down that route, but have not explored it any further as the rounding is doing the job.
It just initially threw me off guard when I was trying to access an array with a decimal number!
I an running Duet Maestro 2 board and have just uploaded firmware V3.01RC6 and the latest DWC with it and the DWC actually shows the machine in the idle state.
The JSONresponses.md file does not mention the 'I' status, although it is in the RepRep documentation.
I have a machine specific web page which is keeping control of the status and scheduling of gcodes to create the particular prints I require, I rely on the 'I' status to let me know when the machine is static and I can rely on the X,Y,Z cords coming back in the status object.
I am finding that although I am moving the X and Y motors in integer steps for probing positions, the position coming back is an approximation of the actual position and I have to round the values to get back to integer figures as indices in the probe point 2-dimensional array.
A typical response debug message
xGrid=1 yGrid=2 xPos=155 yPos=7.977 zPos=59.62 zMinPos=59.219 zMaxPos=59.719
So far all the rounding works OK, but thought it worth mentioning.
I have rebuilt the gantry to include the IR probe and managed to get an ethernet cable into the workshop, so now testing via the DWS.
I expect that there is still finetuning to do with speeds, acceleration etc, but the whole rig is running smoothly, so back to the surface probing.
For testing purposes, I wrote a macro to probe every 2degrees around the circumference ie 180 plot points.
G0 X150 Y0; start of collar - need sensor offset
G91 ; relative movement
; the next section was expanded 180 times as no variables and haven't explored testing against the object yet
G30 S-1 ; single probe
M409 K"move.axes[].machinePosition
G1 Z0.5 F100 ; raise Z by 0.5mm
G1 Y2 ; move by 1 degree
;
G90 ; absolute positioning
This probed OK - it took quite a while though - but I was getting readings back in jason format.
So why am I not just using bed mapping and fade to build up the ring collar? Normal bed mapping assumes that the surface to be found is zero whilst mine is as some arbitrary circumference. All I know is that it will be above 20mm and below 48mm (to allow a 2mm accurate surface to be built).
When variables etc are in place for macros, I wonder if I could do all the arithmetic there assuming I could read the mapping points.
Could there be a key in the object model for the surface map?
At the moment I intend to export all the information to a laptop running the via the web services.
I know in Marlin that a displayed position may be given back before the head had reached that point as gCodes are queued and that the position request could be processed before the movement was finished. If I run the probing macro as above, can I be sure that the figures back from the M409 will be the probe position?
If I send direct codes rr_model?key=move.axes[].machinePosition is this outside of the queue?
I think that I can do all the calculations in javascript on a dedicated web page and make an easy controller for the printer, leaving the RepRap software as standard.
Clive
Thanks for that, the early morning lack of brain, I did go through the notes but obviously missed it - my apologies.
This morning I have spent a couple of hours trying, and failing to update the Maestro2 from RepRap 2.05.1 with the latest firmware 3.01-RC4 so that I could try out the conditional macros and reading of object information.
I cleared the /sys directory on the SD card and only placed the following two files in it.
https://github.com/dc42/RepRapFirmware/releases/download/3.01-RC4/DuetMaestroFirmware.bin
https://github.com/dc42/DuetIAP/blob/v3-dev/Release/iap4s.bin
Using procedure fallback #1
The USB port dropped and became active again, I tried variations of dropping the line via Pronterface or YAT and by totally removing the USB cable and hence power
When I sent M997 S0 I and did not get any messages back
Sending M115 displayed the old system informtion
FIRMWARE_NAME: RepRapFirmware for Duet 2 Maestro FIRMWARE_VERSION: 2.05.1 ELECTRONICS: Duet Maestro 1.0 FIRMWARE_DATE: 2020-02-09
I can't see what I have done wrong.
Are the hardware and firmware compatible?
Am I completely mad.
I have worked out how to mount the dial gauge with sufficient measurement range that it does not need to move using a calibration steel rod of say 20mm diameter between the head and tail stocks, which is then removed when printing on the bamboo.
With the Marlin incarnation I did a 5mm X blocking move and then took a reading and then moved on again. This has the appearance of jerky movement. I don't know how the blocking move works in RapRep to ensure that the 'Z' reading I get is at a true XYZ position before taking the Probe reading.
As a circle is really polygon, how small could steps be made to print part of an arc on the bamboo? I suppose a Gcode could be written to augment the G1 code to work an arc as we know the start and stop degrees and the diameter of the bamboo at those points - interesting times.
@CliveB In one of the initial concepts I had the hot end being driven by the Z motor and the and the opposite side if the gantry being an idler, free running on the bearing rods. The U motor drove the probe in the Z direction. For the probe to be offset by say 90degrees, a new driven axis would be needed as I cannot guarantee that the eccentricity of the bamboo would remain within the range of the gauge (25mm) assuming that I have kept a safety margin to ensure that the gauge never gets to the zero point. Quite an extra structure to be included on the gantry base. Let me think some more.
I appreciate the suggestions.
@dc42 There is much more variance around the circumference than along the length (and hence 'grain') of the bamboo.
By probing at an angle there would be more variance with any bow along the length of the bamboo and the probe not pointing to the virtual centre of the bamboo. Rethinking it, this may not be such a problem as I initially perceived certainly with the dial gauge. Initially I thought of building the whole software from scratch to create a helix printer but soon realised that others knew far more about stepper motors, filament feed etc and that I would be wasting my time trying to reinvent the proverbial wheel.
I then took the simplistic route that as there was less variance along the X axis that I need only probe at 5mm intervals, but the circumferential values need to be checked more carefully.
The Mk2 printer checks at 5mm in the X direction and is OK. My problem come as I step over the boundary of one rectangle to the next in the Y direction. I would only move in the X direction for printing and then move to the next Y position and not do any angular work.
I did think, and indeed tried, the inbuilt bed levelling routines but I would still need to know at what layer I was printing rather than the probed zero point. The variation between hills and valleys can easily be 10mm.
I will take another look - reviews are always an essential part of development.
Hi
Thanks for the response.
Taking the worst case, the outer diameter is 50mm, so circumference of 157mm and at a print width of say 0.4mm gives 392 tracks in the Y direction.I did consider running the dial probe 20mm in front of the hot end and measure every next few points. With stored points, I do not expect that resolution, but lets run with that.
On the X direction with a collar length of 30mm I need to track every 5mm so 7 probe points.
That gives a total of 392x7=2,744.
Now with the 'normal' raising and lowering of the probe, this would just take too long.
I would like to experiment up to half this resolution so say a maximum of 1,400 points.
Until I test everything with the new settings, I do not know what the outcome will be.
With the dial gauge I was not lifting it off the surface between measurements and made sure that no matter how mis-shaped the bamboo was I would always get a positive result. I moved the head at each point to re-centralise the probe. This was quick, but I needed to store all the points - which where this all started.
I have briefly tested the IR probe and more to do. The first problem is that I do not have a starting point for probing - perhaps another course set probe into a trigger pin, whic would give me a point to slow down the probe and do proper measuring.
A few unknows yet. I'm going to play with the probe first to see whether I can run at a reasonable speed and accuracy.