@dc42 said in Guidance regarding Source Code:

The "main program" file is in project CoreNG because it does initialisation first. It calls UrgentInit and later AppMain in the RepRapFirmware project.

Make sure you use the v2-dev branches of RepRapFirmware and CoreNG because that's where development takes place at present.

I can only see 'UrgentInit' being called from '/src/Platform.cpp', but that's under the main tree, not v2-dev branch.

Can't see 'AppMain' being called anywhere.

I know it's a pain to create, but I think a wiki with some overview and guidance to help understand the software structure and flow process would come a long way in helping developers contribute to the duet project.

Not have an attached SD card would be a severe disadvantage, so I suggest you use SPI. Alternatively, use a SAM chip with HSMCI support and more pins. For the Duet Maestro, we chose the 100-pin SAM4S.

Ok, I'll do that. Thanks.

Probably would be a good idea to have some error rejection built in to the upload function. Maybe this can get moved to the DWC/firmware wishlist section?

You are welcome!

Hi Danny,
I am mechanical Engineer and i have my own job that we make plastic injection mold. So we have 3 EDM machines and CNCs..
I used several CAM programs and now i use PowerMill. I just build my 3D printer with duetwifi , duex2 and paneldue 7". I am suffering from slicers because i can't control everything but I get used to it all day.
I developed all electric plastic injection machine controller by using PIC32MZxx now it is testing phase.
Cafer

OK, thanks a lot.

Somehow, my GitHub desktop repository for the DuetWiFiSocketServer was not showing me that there even was a 'dev' branch, so I kept checking and synching to just the master.

I downloaded the ZIP file instead and it works (builds Duet2CombinedFirmware.bin) now.

Window, Preferences, C/C++, Indexer

I had to change the Indexing Strategy to "Use Active Build Configuration" to make them go away.

@kelchm, heated enclosure is more complicated and requires all printer components to handle such temperature.

@vsch, when I was mainly printing ABS, I was thinking to heatup the cooling air too!

I think it is possible to simplify your setup: in order to get a constant temperature, independently of fan speed, I would build a heater element with a high thermal inertia, and make a long exchanger, so air will output at a constant temperature, whatever speed is. For example, a few turns of copper tube cast in a cement bloc, with a good heater cartridge.

Another idea I had, at the time, was to make the air circulate under the bed, as it is also heated up at 110°C. I'm about to receive my silicone bed, so I will see if I can make such setup.

BTW, point 2) is not that easy: if you pause printing, you will have to manage the filament, and may need to purge before restart printing.

Yes it should be fixed. Please test it.

When we change the format, we change the magic value to indicate that.

I didn't update the buildinstructions.md file after I added the Tools folder to the github project. I have done so now.

I have modified the source code to declare the time field in the software reset data as 32 bits unsigned, with casts to and from time_t where necessary. This will be in the 1.21RC3 source code.

Oh, silly me. Thanks for the heads up.

Constant time password comparison is now implemented and will be released in 1.21RC2.

The tacho will only read correctly when the fan is operating at full speed, not if you are using PWM to reduce the speed. But if it is the hot end fan that you want to monitor, you are probably running that at full speed already.

The firmware is already set up to read and display the RPM of one fan. Connect the tacho wire through a diode (1N4148 or similar should work) to pin PB6 on the expansion connector. The cathode of the diode (the end with the stripe) goes to the tacho wire.

Confirmed, it will be FreeRTOS. It's small, well-documented, and the source code is MISRA-compliant. I have started work on adapting RRF to use it already. I am using version 10.0.0.

Yes.

@fma:

Good!

But I think I found the issue. The string:

"${workspace_loc:/${CoreName}/SAM4E8E/cores/arduino/syscalls.o}"

should be :

"${workspace_loc}:/${CoreName}/SAM4E8E/cores/arduino/syscalls.o}"

There where a missing bracket at the end of the workspace_loc var…

Can you confirm?

Recently I was getting this issue intermittently. I think it is an Eclipse bug. So in the latest commit I changed the path to this:

"${workspace_loc}/${CoreName}/SAM4E8E/cores/arduino/syscalls.o"

This seems to have resolved it.

Btw I just experienced the problem that some other users have reported, which is that the expression "${workspace_loc:/${CoreName}/SAM4E8E/cores/arduino/syscalls.o}" in the linker command line got expanded to "". Right-clicking on the project and selecting Refresh resolved it.