Open trustfm opened 5 years ago
timer_stop() is like riding a bike and throwing a stick of wood in your front wheel to stop.
Take a look into dda.c and the homing procedures. You could extend this with a new command, where the max end position is a bit different and it is not zeroing.
The homing works by setting the position to an extreme position (dir * MAX_DELTA_UM
) and stopping when the endstop is triggered. If you add a home command which uses a different target number instead of the extreme position, then I think it will mostly do what you want.
I have a commit that records the position where the endstop was triggered. I needed it for Z-Probing the bed using the BLTouch probe. Maybe you can use something similar for your purposes. The change is here, but I haven't tested it with many different printer configs.
Thank all of you for your support but my problem was bigger. Even with a fresh (unchanged) teacup i got stalls and random "start"strings using putty. For example ( M106 S255 G90 M114 M106 S0 G162 G28 Z M114 G162 Z M106 S255 G28 Z M114 )
got errors and corrupted status messages like X:120.000start ...
I figured out that had to do with the XON/XOFF implementation and my crappy CH340 clone arduino board. I have tested another one with the FTDI chip (arduino duemillanove) and worked perfectly. I have found this source : https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl "Streaming Protocol: Via Flow Control (XON/XOFF)"
What system hw and sw is suggested using teacup ? At this point the options are only FTDI chips ?
got errors and corrupted status messages like X:120.000start ...
It could help, when you post exactly what you've send and received.
Do you have any issues when XON/XOFF is disabled? XON/XOFF disabled is the default setting.
I discovered that either enabled or disabled XON/XOFF CH340 chip stalls. (TX/RX Leds turn off) I made a thread-free freepascal app to test it and i discovered the problem. I always use synaser library. It is pretty stable and cross-platpform
{ In this test
TEACUP + FTDI + XONXOFF ---> WORKS TEACUP + FTDI ---> DO NOT WORKS TEACUP + CH340+ XONXOFF ---> DO NOT WORKS TEACUP + CH340 ---> DO NOT WORKS
}
procedure Connect(ComPort:string); var XONXOFF:boolean; begin BlockSerial:=TBlockSerial.Create; BlockSerial.RaiseExcept:=true; BlockSerial.ConvertLineEnd:=true; //http://synapse.ararat.cz/doku.php/public:howto:readdata try
BlockSerial.LinuxLock:=false;
BlockSerial.Connect(ComPort);
XONXOFF := false;
BlockSerial.Config(250000,8,'N',SB1,XONXOFF,false); //These values work with Grbl. Set the baud rate to 250000 as 8-N-1 (8-bits, no parity, and 1-stop bit.)
BlockSerial.DTR := true;
BlockSerial.RTS := false;
except on E : Exception do begin ShowMessage(E.ClassName + ' error raised, with message : ' + E.Message); end; end; end;
procedure TForm1.ButtonConnectClick(Sender: TObject); begin Connect('COM4'); //COM4
end;
procedure TForm1.ButtonSendReceiveClick(Sender: TObject); var msg:string; i:integer; begin
for i:=0 to 1000 do begin
if BlockSerial.CanWrite(1000) then begin
//BlockSerial.SendString('M114'); //no works
BlockSerial.SendString('M114' + #10);
BlockSerial.SendString('G90' + #10);
BlockSerial.SendString('M114' + #10);
//BlockSerial.SendString('G90' + #10#13);//just wrong
end;
sleep(100);
while BlockSerial.WaitingDataEx > 0 do begin
Memo1.Lines.Add(IntToStr(i) + BlockSerial.Recvstring(-1) );
end;
end;
end;
Hello i have some good news ! I have made a custom arduino trasnsmission tester CH340. I have noticed that arduino clones using CH340 does not work (program stalls) but with trustduino (a mine single PCB arduino board) with the CH340 chip works !!! I include the schematics and PCB of trustdino. The transmission tester is also in the zip file
http://trustfm.net/hardware/Images/Trustduino/tinyserialv1.0.zip
PS : my crude endstop implementation with the timer_stop(); queue_flush(); timer_init(); sequence seems to work too with the FTDI and mine trustduino CH340 based board !!!
I am using teacup as a pick and place machine. I have variable height (Z) colums so i use ZMax endstop as sensor. I use the G162 Z100 Command for example This goes down 100 if i get no click i know that the columd is empty else i do a pick and place movement
This is implemented like this :
Clock.h uint8_t ZPolling; int32_t ZMaxRuntime;
clock.cpp
gcode_process.c
Now the question : extremely rarely we get the machine stalled is there any possibility that specially timer_stop(); queue_flush(); timer_init(); is the problem ? Can this be implemented differently ? Via serial i get "E:start" seems to restart arduino ...
I have tried to not flush the hole queue i have made a custom queue_next but does not seem to work as expected. Thank you for your time