Topics created by jcsb1994

@bearer oups it is not part of the string, its just a pasting mistake

@jcsb1994 said in Uploading and running files from G code commands:

learning bash doesnt seem too long.
I would need the project to be cross platform. Is bash only usable with linux?

bash works pretty much everywhere its installed, but the stty command and using redirects to send data to the serial port isn't very portable outside of linux, nor the autodetection of the correct usb-serial port.

you can do the same in c/c++ though

get the size of the file to be sent send the M559 command with the filename and size over serial send the contents of the file over serial after having sendt M559 once the duet has received the correct number of bytes according to the filesize it will store the file and return a "Done saving file" and "ok" string.

you also need to sort out choosing, opening, and closing the serial port for the duet.

I am not sure I understand the solution you offered. The duet was connected to a Pi's USB (which is linux so bash works) and then the Pi was connected to your computer?

I log in to the pi over the network/ssh, so for all intents and purpose I'm using the pi as a linux computer with the Duet connected over its serial usb.

@jcsb1994 I don't know if you are still working on this but I think I was having the same issues. I never actually timed the moves on the 2.x firmware but it seemed like the moves completed in the correct amount of time. When I updated to the 3.1.1 firmware my motors went way faster than they were supposed to. So I think they changed how the feedrates are calculated.

Now I think that the feedrate is only calculated using the X, Y, and Z values. Meaning that with your initial example of G1 X-25 Y-25 Z-25 U-25 F1500 to find out how long the move is going to take you first need to find how long the diagonal move will be.

This will be 25^2 + 25^2 + 25^2 = c^2, c will equal 43.3. Then you divide by the feedrate and multiply by 60 to get the length of time the move will take in seconds. Meaning that the time for this move should be 1.73 s. I did the math for the feedrate of 300 as well and I got that the move should take 8.66 s.

The math seems to match what you are getting but it would be nice to confirm that this is actually what is going on and see if these changes were implemented when updating to firmware 3.x.

I finally managed to make it work. I switched my 4 axes to X, Y, Z and U. I do not know why but trying A B U V didn't work no matter what I did. It might be because I still had my XYZ axis setup, so I really had 7 axes, and maybe the endstops were just checking the first axis they were setup for (i.e. X instead of A, Y instead of B, and Z instead of U)

Thanks a lot for your help @fcwilt and @Phaedrux

@fcwilt That would work too ☺

@jcsb1994 said in Dead time between G1 commands over USB:

I am trying to move my motors for specific distances within a very precise amount of time, ex: 2cm in 1.5 sec, and then I do back and forths with my motor (sending repeatedly the same G1 command but inverting the direction, ex: G1 X10, G1 X-10 infinitely).

If you send those commands as a block, then there should be no gaps between then, just the acceleration and deceleration at the start and end of each move.

Please provide the calculations you have done that lead to think that the movement is 3% too slow.