I have it working with the following bash script:

SWCLK=25 SWDIO=24 SRST=18 echo "Exporting SWCLK and SRST pins." echo $SWCLK > /sys/class/gpio/export echo $SRST > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio$SWCLK/direction echo "out" > /sys/class/gpio/gpio$SRST/direction echo "Setting SWCLK low and pulsing SRST." echo "0" > /sys/class/gpio/gpio$SWCLK/value echo "0" > /sys/class/gpio/gpio$SRST/value echo "1" > /sys/class/gpio/gpio$SRST/value echo "Unexporting SWCLK and SRST pins." echo $SWCLK > /sys/class/gpio/unexport echo $SRST > /sys/class/gpio/unexport echo "Ready for OpenOCD." openocd -c "adapter driver bcm2835gpio; \\ bcm2835gpio peripheral_base 0xFE000000; \\ bcm2835gpio speed_coeffs 236181 60; \\ adapter gpio swclk $SWCLK; \\ adapter gpio swdio $SWDIO; \\ adapter gpio srst $SRST; \\ transport select swd; \\ set CHIPNAME samc21; \\ source [find target/at91samdXX.cfg]; \\ reset_config srst_only; \\ adapter speed 276; \\ init; \\ reset; \\ reset; \\ at91samd chip-erase; \\ at91samd bootloader 0; \\ program Duet3Bootloader-SAMC21.elf verify; \\ reset; \\ shutdown" echo "Done."

This is adapted from here.

@dc42 thank you.
i am not try to build it. but it's not working and giving error.
310eafdf-9b7d-4057-af6e-ca4e5c8a2da5-image.png

@Thugmek we've never used debuggers with Duet 2. Older version Duet 2 boards do expose the JTAG/SWD pins but newer ones don't. All Duet 3 boards expose the SWD pins.

If the firmware crashes, the crash details are written to flash memory and can be retrieved using M122. We use the linker map file and assembler files generated by the compiler to identify the exact point at which it crashed. We usually find that sufficient to identify the bug.

@wieman01 Note that the dependencies and branches for the 3.5beta are not yet documented on the wiki, you may need to figure that out unless it's added before you start.

@dc42 thank you! (confirmed: works for me too now)

@dc42 I watch a lot of videos about electronics engineering and the stuff people are doing these days is pretty cool given the high level interfaces are available right at the hardware now.

I'm curious, my impression of the product line is that it's meant to be very stable, prioritizing it above everything else.

Do you think it would be beneficial to open up more of the toolset to people who want to develop, debug, etc. at a more causal commitment level? Just one example is to document how to build a test rig? Maybe that's too complicated, so the next best thing would be to figure out how to make it less complicated and start from there? I don't really know the subject material that well, so my suggestions could be way off, but I think you get the gist.

One of the great things about open source is the amount of human-power you can get for effectively free if you make it easy enough for people to contribute.

For myself,

I wanted to try to write unit tests for algorithms, but I couldn't find a way to "run" the code. I didn't know if there were any entry points already there to make it possible to write unit tests; aside from starting from scratch with some OTS unit testing framework and start figuring out how to mock, exec, etc. Any pointers?

@Mark_XYZ Custom array variables will be supported in 3.5-b1.

@dc42 “you could either detect USB disconnection/reconnection in your C# program…” Yes, I was asking how to do that. It is possible but not trivial to get notification for this on a particular device. Further, it needs deeper knowledge of the actual driver providing the serial interface to the application, which I don’t have. So I asked if anyone might have this.
But my approach was wrong. I don’t have that info, but I don’t need it either: The right way to do it is to hook to the general device event and know that some device dis-/reconnected. That is enough, I can then look at the uptime or a variable to find out if it was the Duet.

@gnydick yes I've read about that interesting algorithm before. I know of one place where the reciprocal of a square root is used, so it could perhaps be used there. However, most of the processors we use now support a fast floating point square root instruction.

@T3P3Tony HI Tony, installed the new board, uploaded the latest firmware and all is well, This issue is closed on my end. Thanks so much for your assistance to all @elmoret @droftarts @Phaedrux @dc42

It was in fact the librairies, marked solved

@KOlasmics I'm glad you found a solution!

@dc42 Thank you for the detailed explanation!

@rschrem I suggest you take a look at the M670 command.

@x-stride I don't hink it's worth implementing this, as there is no good reason this concept goes "viral"

Disadvantages:

the rails for the delta can be shorter, but without any Z-motion they will wear out quickly the bed mechanism of a CoreXY is usually slower and complex. You'll spend more money on it than you save for shorter Delta rails how would you calibrate the Delta

You can still find a workaround by calling the bed's axis "W" and postprocess the gcode files (replace all "Z" with "W")
You have to change the homing files and overwrite the z-height found by the Delta calibration.
No big deal, if you're familiar with the RRF universe.

@dc42 Sorry for the late response, I've needed to switch to some other tasks. Will come back to the topic within two weeks, and if you'll be able to continue then - it would be great! Thank you. Artem

@phaedrux Sure,

It's the raise 3d pro tablet!, totally closed of course.

it must be usb to serial comm's and the arduino was just to prove a point, that the host tablet will recognize the correct VID_PID the duet will take place of the arduino.

I would like to use duwt wifi under host control of the raise tablet (printing over usb basically) but i need to change the vendor id and product id of the duet.

thank you

@bot said in Input shaping cant work with short move:

@ccs86 sadly this is why I've not yet tried IS. All my prints are highly segmented to the point that IS would seldom play a role.

Glad I'm not alone there. I really try to avoid sharp outside corners in most of my designs, so the current IS implementation really falls short for me.

I'm hopeful that there is a solution to the OP's problem and ours all in one.

@kulitorum to compile under Windows you will need to do at least the following:

Set your Windows compiler to C++17 or later Deal with any #pragma directives and any gcc-specific attributes. Declaring __attribute(...)__ as a macro that expands to nothing may be a good start. Replace all the FreeRTOS and CoreN2G project files that are needed by RRF by suitable functions. Mostly they will be do-nothing stubs. RRFLibraries includes a couple of assembler functions that you will need to replace by suitable C code, but should otherwise compile.

HTH David