Posts made by carlosspr

I am facing the same problem with Release 3.4.2rc1. Did you solve the issue?.
For me it prints OK, but if I heat the bed manually the probe deploys/retract like mad.

@carlosspr Solved. I was missing M584 drive mapping on config.g

I have updated and I can only use one tool.
On the tool configuration I have the following error:

M563 S"Yellow" P1 D1 H1 F0
Error: Tool creation: bad drive number

however on previous release this command was working fine.

maybe you need to enable cold extrusion with M302 P1 and afterwards disable with M302 P0

@zzing I remember to have had some issues when speed was too low.
In my settings I have F2000. For the rest, the settings seem OK to me if the 25% current allows you to move the drivers (my minimum was 35% and below that it would fail).

@dc42 Yes they are mapped to drivers 3 and 4. The result of M584 is : Driver Assignments X0 Y1 Z2 E3:4, 3 axes visible.

Same here using RepRapFirmware 3.0beta3 (2019-05-16b1) . In my case I have two tools (two extruders and one heater). The following is the configuration of my TOOLS section:

;_____ TOOLS
M563 P0 D0 H1                       ; Define tool 0 to use extruder drive 0 and heater 1
G10 P0 S0 R0 X0 Y0                  ; set tool 0 temperatures and offsets
M572 D0 S0.1			    ; Pressure advance enable for extruder 0

M563 P1 D1 H1                       ; Define tool 1 to use extruder drive 1 and heater 1
G10 P1 S0 R0 X0 Y0                  ; set tool 1 temperatures and offsets
M572 D1 S0.1			    ; Pressure advance enable for extruder 1

None of the tools would move, neither with temp nor forcing cold extrusion with M302

I have finally managed to compile Reprapfirmware (had lots of problem with the ARM toolchain). I have tried to implement the S-Curve based in Bezier algorithm, but I cannot make it work.

I am posting here findings and reasoning to see if someone in the forum can see the errors and where it fails and/or clarify possible wrong concepts. i have the feeling that it might be related to unit conversions.... but I can not find the error.

There is not much documentation on how Reprap implements the Movement, so I have tried to understand it by reading the code. However, due to real-time optimizations the implementations are hard to follow and my findings can be wrong.

As far as I understood, the class Move controls all movement of the RepRap machine, both along its axes, and in its extruder drives.

The planner is implementer in DDA.h/DDa.cpp and the Control of the steppers in DriveMovement.h/Drivemovement.cpp

TRAJECTORY PLANNER (DDA): Implements a line tracing using Bresenham algorithm. In other words, it buffers movement commands and manages the movement profile plan. This ensure that our printer moves as fast as is possible within the kinematic constant constraints at the configuration.

This are the variables used by the motion planner to manage acceleration (defined in DDA.h).

           float accelDistance; 
           float steadyDistance; 
           float decelDistance;  
           float requestedSpeed;
           float startSpeed;  
           float topSpeed;  
           float endSpeed; 
           float targetNextSpeed;

All speed units are in mm/s

STEP CONTROL: The step control is performed at Movement.h and Movement.cpp. The process determines for each drive instants of the time t (in processor [cycles]) when pulses (steps) are generated based on the calculated profile.

There are two methods – two group of algorithms - for calculating instants of time when pulses must be generated. They are named as: “time per step” and “steps per time”. Reprap uses "time per step" with the following operation mode (as I could understand from the code):

• 1./ calculate time period to next pulse (nextCalcStepTime),
• 2./ wait until that much time period elapses,
• 3./ generate next pulse and
• 4./ go back to step (1) and repeat until desired number of pulses is over .

It is not very clear to me the algorithm followed to calculate nextCalcStepTime and I could see some compensation clocks on the formula which also I do not quite understand well.

In order to add an S-Curve profile, I followed Marlin approach to use the same trapezoid generated by DDA and only implemented changes in DriveMovement.

The first step I did was to draw the trapezoid using as speed units steps/s and the variables available in the code:

The trapezoid is the shape the speed curve over time in steps per second.

• It starts at step=0, accelerates until accelStopStep,
• then keeps going at topSpeed (constant speed) until it reaches decelStartStep
• after which it decelerates until the trapezoid generator is reset to next DDA at totalSteps.

The first pulse (step) controller generates at the start of motion, at the start of the phase of acceleration, i.e. at the step time t=0. After the first pulse is generated, the controller needs to calculate the time period until the next pulse (nextCalcStepTime) wait until this period has elapsed, and then generate the next pulse, at step time t=1. This will go on until the desired position is achieved, or in other words, the desired number of pulses (steps) has been generated.

Since after each pulse the motor makes one step of distance 1/stepsPerMm, the time delay between two successive steps is given by

 *nextCalcStepTime* = 1 / ( stepsPerMm * V(t) )

Instead of a linear speed in the acceleration and deceleration phases, V(t) is replaced by the quintic (fifth-degree) Bézier polynomial for the velocity curve:

       V(t) = V_f(t) = A*t^5 + B*t^4 + C*t^3 + D*t^2 + E*t + F

And this is calculated using the Bezier S-Curve with the same code developed by Eduardo José Tagle (Marlin).

The trapezoid generator state in DriveMovement.cpp contains the following information, that we will use to create and evaluate the Bézier curve:

   accelStopStep		    		[TS] = The total count of steps for this movement. (=distance)
   dda.startSpeed * stepsPerMm   [VI] = The initial steps per second (=velocity)
   dda.topSpeed * stepsPerMm     [VF] = The ending steps per second  (=velocity)
   nextStep 						[CS] = count of steps completed(=distance until now or current step)

In DriveMovement:Prepare, at the start of each trapezoid, I calculated the coefficients A,B,C,F and Advance [AV], as follows:

   *      A =  6*128*(VF - VI) =  768*(VF - VI)
   *      B = 15*128*(VI - VF) = 1920*(VI - VF)
   *      C = 10*128*(VF - VI) = 1280*(VF - VI)
   *      F =    128*VI        =  128*VI
   *     AV = (1<<32)/TS      ~= 0xFFFFFFFF / TS (To use ARM UDIV, that is 32 bits) (this is computed at the planner, to offload expensive calculations from the ISR)
  **/

For the deceleration part, we use the same approach, but adapted to the initial velocity and final velocity of the segment:

	   *  totalSteps - decelStartStep	[TS] = The total count of steps for this movement. (=distance)
	   *  dda.topSpeed * stepsPerMm     [VI] = The initial steps per second (=velocity)
	   *  dda.endSpeed * stepsPerMm     [VF] = The ending steps per second  (=velocity)
	   *  nextStep 			     [CS] = count of steps completed(=distance until now or current step)

Finally, in DriveMovement::CalcNextStepTime we calculate nextCalcStepTime for the S-Curve profile

nextCalcStepTime = 1 / (eval_bezier_curve(nextStep) * stepsPerMm);
nextCalcStepTime = nextCalcStepTime * StepClockRate;

The time is multiplied by the StepClockRate to get the number of clock cycles.
Probably I would need to add compensation Clocks.... but I do not understand why this is in the formula on the current firmware and could not test because it does not work properly.

I could provide the Source code from DriveMovement.cpp and DriveMovement.h which are the only parts changed in case that anyone wants to investigate further......

I have changed them for stall detection "on the fly" using M913 as a percentage of the maximum current set by M906.

@guillegef said in Problemas graves de temperarura en motores:

M916

Shall be M913...

I have dome some measurements to validate the compensation for my capacitive probe (this would also apply to inductive probes or probes that drift with temperature). The following are my results:

1./ Calibrate the Z probe trigger height to zero at near room temperature
2./ Run G31 S-1 and annotate the Trigger height reported. (I run it on a script 25 times and record the average value).
3.- Repeat the process increasing temperature 10C on each run.

We end up with a table like this:

Temperature Trigger Height (mm)
30 1.92944
40 1.90196
50 1.84032
60 1.80004
70 1.81672
80 1.66856
90 1.3272
100 1.28496
110 1.23432

If we plot these values, we can see that the relationship compared with a linear trendline:

Now I use the trendline as the "ground truth" for the trigger distance and calculate the errors versus the average measurements. On a second colums I calculate the error versus a fixed heigh at 80C without temperature compensation.
Temp Error (mm)
(linear – Measurement) (linear – fixed height at 80C)
30 0.10134222222219 0.260880000000001
40 0.03233555555552 0.2334
50 -0.00251111111115 0.171760000000001
60 -0.05871777777782 0.13148
70 -0.17188444444449 0.148160000000001
80 -0.120211111111159 0
90 0.12466222222217 -0.341359999999999
100 0.0704155555555 -0.383599999999999
110 0.02456888888883 -0.43424

Definitely the temperature compensation reduces error, but the accuracy is still not so good.

I understand this feature is going to be deprecated and it might make sense, but then different solutions to the problem might be needed. Some solutions that I came across are:

• Setup the G31 code for the specific bed temperature on the Slicer (under filament custom start G code) - I could perform the mesh leveling on this section, with different Trigger height based on filament bed requirements.

• I had the idea to use the motor stall probe on the same point of the bed every time to run a G30, the change the probe to the capacitive/inductive, report the trigger and then update the G31 parameter. With this update I would peroform a mesh level with the reported trigger height. If would be great if the G30 S-1 could update automatically the G31 value based on the reading )or an average of readings).

If somebody has other solutions, I would be glad to try them.

I am in a similar situation with firmware 2.0RTORC4.
I am using Sensorless Homing (stall effect) for G30 to find the Z=0. Then I would use G29 with a capacitive probe for mesh leveling. I found that I can run G30 and then manually move to Z0 with great precision, then I run a G30 S-1 with the capacitive probe and I get the offset value. I would use this offset for mesh leveling, but when it comes to the print, the height would be off. I have narrowed down the issue to temperature drift of the probe which, added to the natural tolerance error of the sensor, can vary a lot from a cold bed to a hot bed.

Now I am in the process to test if I can compensate this temperature drift with G31 using the S and C parameters that would allow to define some reference temperature and linear compensation, but I need to do some measurements to calculate the C coefficient before I put this to work and see repeatability patterns and improvements.

....also my capacitive probe is mounted in parallel to the ED3 J6 and receives the air flow from the cooling fan, which throws hot air and would create a micro climate around the probe, which might not be so good to fight thermal drifts....

@bartolomeus I can see a few reasons that might be causing your behaviour in the code:

G1 S1 X-320 -> You might want to add a speed to the homing ( G1 S1 X-320 FXXXX). Sensorless homing is very sensitive to speed variations and triying with different speeds will produce different results.

G1 X-5 Y-5 -> If Y was not pre-homed this will abort the script on that line, because no moves are allowed on the axis unless it is homed, therefore your motors will be left with 30% current add a G1 S1 Y-320 FXXXX before the line.

I also noticed that sometimes the first homing move fails, probabl because the motor was "off" and the currents have not stabilized, so I runt the command G1 S1 X-320 and in between I wait 300 ms to let the current transients to stabilize (you do this with the command G4 300).

Hope this helps.

@dc42 Thanks for the answer. This means that this is a linear relationship and I could calculate the offset for a certain Bed temperature and the firmware would recalculate for different temperatures using a linear relationship [Offset_at_T'] = [Offset_at_T] + C*(T'-T) ?
I find it is really usefull to compensate on temperature drifts for Inductive and capacitive probes. I am using a capacitive probe and the drift can be more and 0.1mm in 80C, which is driving me crazy for Mesh leveling, because it is changing the height of my nozzle and this could be a very good fix.
I will try tonight.

@niocio01 You can find information about the Lua interpreter at the official web page: https://www.lua.org/download.html

Lua RTOS for ESP8266: adds a LUA interpreter on top or Free RTOS.

Probably the cleaner interface would be to use the serial communication port, and use LUA to put content (G coded) and read content, that could be parsed and scripted.

I do not know how (un)easily this would integrate with the current code, since some M code should probably be created to call the lua interpreter that would then execute the scripts.

That would be very interesting.

Probably a quick implementation could be done using Lua scripting.
There is an implementation of Lua for Free RTOS and now that Duet is built on top of Free RTOS it could be possible to add a thread with lua scripting interface.

Once lua is in place, it could be possible to send G code or read the serial interface and parse results, then use the results on any script. There are several projects on Git with code to send Gcode from Lua or to read a serial communications where command outputs would be posted.

According to the Wiki, the facility to setup a G31 temperature and compensation tables is deprecated and likely to be removed in a future version of RepRapFirmware (C and S parameters).

Both capacitive and inductive proximity sensors drift with temperature and some clarification on the logic and feature might help increasing accuracy of these sensors.

Is it possible to explain the calculation behind the logic and hot to setup the C and S parameters?. I would like to play with the feature to improve the accuracy of my probes.

@barracuda72 Step 3 would leave bed ON, therefore covering your use case.

In general I would replace the step 6 by a "Macro" (something like on heaterfault0.g). This macro could include the actions as described on M81 or be configured by the user to its preferences.
It is not the same a heater fault on the Bed than a heater fault on the nozzle. The basic security steps could cover any failure modes, but a macro associated to the heaters would be the more flexible option and would give room for improvements without further code changes required. Something like the Toolchange macros for each defined tool.

@misan The basic principle in your blog is correct, but there are some constraints that need to be applied and they bring some complications to take into account.
You are modeling the acceleration as (1-cos(t)). The fists constraints to apply are:

• Your motor is physically limited by a maximum acceleration (let’s call it Amax) and we would like to reach the maximum acceleration (if possible) to reach the travel constant speed in the shortest time.
• You might want to enter the segment with some initial acceleration (let’s call it a0)
  Then you mathematical model for the acceleration becomes a(t) = a0 + (Amax-a0)(1-cos(t)).
  Now we would lie a “jerk free” movement, therefore we need to apply another constraint and this is that the derivative of the acceleration shall be zero ant the beginning and the end of the acceleration phase. This gives you a limitation on the time for the acceleration phase
  Tacc= Amaxpi/Jmax
  This means that we cannot use the same trapezoid calculated for linear acceleration, where the acceleration goes from a0 to Amax instantly. For the trapezoids to be the same, the area under the graphs (this area equals the final velocity) shall be the same, this means that the sinusoidal model would “exceed” the maximum acceleration. I have used your graph to illustrate this:

Actually Marlin implementation using S-Curves has some benefits over the sinusoidal model:

• They use the same trapezoid logic used for instant acceleration model, thy know that they are exceeding the maximum acceleration configured on the firmware, and they are taking some risks here. The truth is that I have several Nema17 and I could not find manufacturer specs for maximum acceleration on any of the brands, and at the end of the day, the settings in my firmware are totally experimental,….
• Their model does not have the constraint of Acceleration time to obtain zero jerk that is required for sinusoidal models.

On my Ideal model I would also like to consider several use cases:

• Some movements are too short/fast and the Maximum desired kinematics (desired speed, maximum acceleration) can not be reached on the distance moved. This would impact/constraint the next segment with initial kinematics (final state of previous move), therefore the model shall consider to enter the segment with some initial acceleration and velocity.
• Some movements might ask for a travel velocity that can not be reached with a simple S-curve (we have a top on the maximum acceleration), and we the need to consider a "flat" acceleration phase until the travel speed is reached.
• Ideally physical constraints are specified by manufacturers and the firmware would respect them.

But it is also true that some approaches, even if the bend the rules (like Marlin and the Aceleration limit), might work easier and better on a real world. At the end of the day, if the model is so complex that it can not be implemented in realtime.... then is useless for now until future processors make them a reality.

Same for me. At some point the Web Interface lost connection and the print stopped. I was able to access the board via Telnet and generate an M122, but several atpempts needed before gettign the log because the Telnet would close connection before dumping all information.

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC2 running on Duet WiFi 1.02 or later
Board ID: 08DDM-9FAM2-LW4S4-6J1D8-3SJ6M-TMVZY
Used output buffers: 2 of 20 (8 max)
=== RTOS ===
Static ram: 28564
Dynamic ram: 96048 of which 0 recycled
Exception stack ram used: 288
Never used ram: 6172
Task NETWORK ready, free stack 1408
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3804
=== Platform ===
Last reset 00:01:23 ago, cause: software
Last software reset time unknown, reason: Hard fault, spinning module Platform, available RAM 5864 bytes (slot 3)
Software reset code 0x4030 HFSR 0x40000000, CFSR 0x00000400, ICSR 0x0041f803, BFAR 0xe000ed38, SP 0x20005004
Stack: 0040b539 00433b84 01000200 f8000000 406e386f 3edb6db7 b7b4d800 3e178897 3e1cd04f 41700000 3e23e0ac 3e3a4c97 3e63a87e 3e9258c9 3cd1cfc0 3f317180 3f800000 60000000 40382d26 60000010 004448bb 20005070 200050b8 00000001
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 37.5, current 37.7, max 38.0
Supply voltage: min 23.9, current 24.0, max 24.2, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 1970-01-01 00:00:00
Slowest main loop (seconds): 0.010376; fastest: 0.000075
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(2) Telnet(0)
HTTP sessions: 0 of 8

• WiFi -
  Network state is running
  WiFi module is connected to access point
  Failed messages: pending 0, notready 0, noresp 0
  Failed to get WiFi status
  Socket states: 2 0 0 0 0 0 0 0
  === Expansion ===