New RepRapFirmware 3.0 early beta

gtj0

@dc42 said in New RepRapFirmware 3.0 early beta:

I've just committed new source code to fix a number of RRF3 bugs, including issues with temperature readings.

Yep, temps now read correctly. Thanks!

dc42

@smoki3 said in New RepRapFirmware 3.0 early beta:

@dc42
It was definitely not like this on 2.02 and the older 3.0.

And its a really wired behaviour. Because I use:

; tfree0.g
; called when tool 0 is freed
;
; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
G91
G1 Z10 F7200
G90
G53 G1 X0 F25000 ;XPOS
G53 G1 Y190
G53 G1 Y195 F5000
M400
M98 P"/macros/Toolhead/1. Toolhead unlock"
G4 P320
G53 G1 Y207 F5000
M400
G53 G1 Y165 F25000
M400

; tpre1.g
; called before tool 0 is selected
;
; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
G1 X76 F25000
M400
G1 Y192
M400
M98 P"/macros/Toolhead/1. Toolhead unlock"
G4 P400
G1 Y207 F5000
M116 P3
M400
M98 P"/macros/Toolhead/2. Toolhead lock"
G4 P260
G1 Y150 F15000

The I only expect that only a X movement is done while the start of the tpre1.g but it first moves in X and Y.

@smoki3, I am looking into this but I need your config.g file, also the toolhead unlock files that you call from the tool change files.

smoki3

@dc42 I will provide it until next week. I am on vacation

gtj0

@dc42 Homing seems to be broken at the moment.
If the axis is already homed and it's endstop is triggered, you can't run the homing sequence again without getting a Error: G0/G1: insufficient axes homed and the axis changing state to unhomed.

Example... Here's my CoreXY homex.g file...

G91               ; relative positioning
G1 H1 X-490 F3600 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F3600       ; go back a few mm
G1 H1 X-490 F360  ; move slowly to X axis endstop once more (second pass)
G90               ; absolute positioning

If the endstop isn't triggered the homing sequence runs. If it's already homed, I get the error.

Also, when it does work, it sometimes reports the tool at a small distance from 0. For instance, if I home X, sometimes the tool is reported at 0.000, sometimes, 0.105, sometimes 0.038, etc.

gtj0

Oh, here's another one. I'm not sure of this is related to the tool offset discussion but when RRF initializes, the Z axis height displays the offset from the heightmap so as you move the X or Y axes, the Z axis position display changes.

NoSkillzEngineer

Too bad the duet forum can't be merged with like a Discord server, that would be pretty cool and pretty convenient with how you can like tag or pin people or everyone in that particular thread, I'd be way more active on a Discord server, just saying, phone mobile notifications for the discord app are kinda nice, I have it notify my only when someone specifically tags me.

@dc42

Not sure if you're interested in this at all, but I have have access to a few industrial machines, I found a way to get the list of the supported G-Codes and M-Codes in Fanuc's controllers. I have access to a 2014 Doosan Puma GT2100 CNC lathe and idk what year Doosan DNM 5700 mill and a very large and rather new Haas GR712 and two ProtoTrak controllers.

Perhaps I'm unfamiliar with the specific intent of the Duet 3.0, but I vaguely remember a conversation with you about standardizing the G-Codes at least, as M-Codes tend to be manufacturer and/or machine application specific. I'll get lists/pictures of all the G-Codes and M-Codes if you want and if there's any other information you want/need from the Fanuc controllers (kinda wanna reverse engineer their controller myself cuz they are the standard for industrial CNC controllers). It's for several networking and interface ports, can't imagine it would be that hard to get code from the controllers:)

Anything you wanna know about some of the industrial controllers we have in our shop??

Oh, and this is something cool I discovered is Macro B Programming on Fanuc controllers. Click here for a PDF on my Google drive about Macro B Programming inside Fanuc controllers

It allows parametric hand programming for canned cycles like G71 on a CNC lathe which is a roughing operation.

link to pictures of my program I created in a couple minutes

grizewald

@noskillzengineer said in New RepRapFirmware 3.0 early beta:

Too bad the duet forum can't be merged with like a Discord server, that would be pretty cool and pretty convenient with how you can like tag or pin people or everyone in that particular thread, I'd be way more active on a Discord server, just saying, phone mobile notifications for the discord app are kinda nice, I have it notify my only when someone specifically tags me.

I for one would object to this very much, for several reasons:

The T&C for using Discord are "all your comments belong to us".
Mobile devices with their ultra slow on-screen keyboards are an incredibly frustrating experience for reading and creating textual and graphic content. Give me a computer with a proper keyboard every time.
Things like Discord servers and F***book are awful for storing information in a form where you can search for it and organise it in a structured way. They might be good for people with an attention span of minutes, but not for structured discussions.
Discord and other such platforms are not indexed by web search engines, making any information that they hold even more inaccessible.

gtj0

@dc42 Just FYI... The current v3-dev RRF branch isn't building for the Duet2...

arm-none-eabi-gcc -L"/usr/src/3d/dc42/workspace/CoreNG/SAM4E8E" -L"/usr/src/3d/dc42/workspace/CoreNG/SAM4E8E" -L"/usr/src/3d/dc42/workspace/FreeRTOS/SAM4E" -L"/usr/src/3d/dc42/workspace/RRFLibraries/SAM4E_RTOS" -Os --specs=nano.specs -Wl,--gc-sections -Wl,--fatal-warnings -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -T"/usr/src/3d/dc42/workspace/CoreNG/variants/duetNG/linker_scripts/gcc/flash.ld" -Wl,-Map,"/usr/src/3d/dc42/workspace/RepRapFirmware/Duet2_RTOS/Duet2CombinedFirmware.map" -o "Duet2CombinedFirmware.elf" -mthumb -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -Wl,--start-group "/usr/src/3d/dc42/workspace/CoreNG/SAM4E8E/cores/arduino/syscalls.o"  ./src/Tools/Filament.o ./src/Tools/Spindle.o ./src/Tools/Tool.o  ./src/Storage/CRC32.o ./src/Storage/FileInfoParser.o ./src/Storage/FileStore.o ./src/Storage/MassStorage.o  ./src/ObjectModel/ObjectModel.o  ./src/Networking/W5500Ethernet/Wiznet/Internet/DHCP/dhcp.o  ./src/Networking/W5500Ethernet/Wiznet/Ethernet/W5500/w5500.o  ./src/Networking/W5500Ethernet/Wiznet/Ethernet/WizSpi.o ./src/Networking/W5500Ethernet/Wiznet/Ethernet/socketlib.o ./src/Networking/W5500Ethernet/Wiznet/Ethernet/wizchip_conf.o  ./src/Networking/W5500Ethernet/W5500Interface.o ./src/Networking/W5500Ethernet/W5500Socket.o  ./src/Networking/ESP8266WiFi/WiFiInterface.o ./src/Networking/ESP8266WiFi/WiFiSocket.o ./src/Networking/ESP8266WiFi/WifiFirmwareUploader.o  ./src/Networking/FirmwareUpdater.o ./src/Networking/FtpResponder.o ./src/Networking/HttpResponder.o ./src/Networking/Network.o ./src/Networking/NetworkBuffer.o ./src/Networking/NetworkResponder.o ./src/Networking/TelnetResponder.o ./src/Networking/UploadingNetworkResponder.o  ./src/Movement/StepperDrivers/DriverMode.o ./src/Movement/StepperDrivers/TMC22xx.o ./src/Movement/StepperDrivers/TMC2660.o ./src/Movement/StepperDrivers/TMC51xx.o  ./src/Movement/Kinematics/CoreKinematics.o ./src/Movement/Kinematics/HangprinterKinematics.o ./src/Movement/Kinematics/Kinematics.o ./src/Movement/Kinematics/LinearDeltaKinematics.o ./src/Movement/Kinematics/PolarKinematics.o ./src/Movement/Kinematics/RotaryDeltaKinematics.o ./src/Movement/Kinematics/ScaraKinematics.o ./src/Movement/Kinematics/ZLeadscrewKinematics.o  ./src/Movement/HeightControl/HeightController.o  ./src/Movement/BedProbing/Grid.o ./src/Movement/BedProbing/RandomProbePointSet.o  ./src/Movement/DDA.o ./src/Movement/DDARing.o ./src/Movement/DriveMovement.o ./src/Movement/Move.o ./src/Movement/RawMove.o ./src/Movement/StepTimer.o  ./src/Libraries/sha1/sha1.o  ./src/Libraries/Fatfs/diskio.o ./src/Libraries/Fatfs/fattime_rtc.o ./src/Libraries/Fatfs/ff.o ./src/Libraries/Fatfs/ffunicode.o  ./src/Heating/Sensors/CpuTemperatureSensor.o ./src/Heating/Sensors/CurrentLoopTemperatureSensor.o ./src/Heating/Sensors/DhtSensor.o ./src/Heating/Sensors/LinearAnalogSensor.o ./src/Heating/Sensors/RemoteSensor.o ./src/Heating/Sensors/RtdSensor31865.o ./src/Heating/Sensors/SensorWithPort.o ./src/Heating/Sensors/SpiTemperatureSensor.o ./src/Heating/Sensors/TemperatureSensor.o ./src/Heating/Sensors/Thermistor.o ./src/Heating/Sensors/ThermocoupleSensor31855.o ./src/Heating/Sensors/ThermocoupleSensor31856.o ./src/Heating/Sensors/TmcDriverTemperatureSensor.o  ./src/Heating/FOPDT.o ./src/Heating/Heat.o ./src/Heating/Heater.o ./src/Heating/HeaterProtection.o ./src/Heating/LocalHeater.o ./src/Heating/RemoteHeater.o ./src/Heating/TemperatureError.o  ./src/Hardware/DmacManager.o ./src/Hardware/I2C.o ./src/Hardware/IoPorts.o  ./src/GCodes/GCodeBuffer/BinaryParser.o ./src/GCodes/GCodeBuffer/GCodeBuffer.o ./src/GCodes/GCodeBuffer/StringParser.o  ./src/GCodes/GCodeChannel.o ./src/GCodes/GCodeInput.o ./src/GCodes/GCodeMachineState.o ./src/GCodes/GCodeQueue.o ./src/GCodes/GCodes.o ./src/GCodes/GCodes2.o ./src/GCodes/GCodes3.o ./src/GCodes/GCodes4.o ./src/GCodes/RestorePoint.o ./src/GCodes/Trigger.o  ./src/FilamentMonitors/Duet3DFilamentMonitor.o ./src/FilamentMonitors/FilamentMonitor.o ./src/FilamentMonitors/LaserFilamentMonitor.o ./src/FilamentMonitors/PulsedFilamentMonitor.o ./src/FilamentMonitors/RotatingMagnetFilamentMonitor.o ./src/FilamentMonitors/SimpleFilamentMonitor.o  ./src/Fans/DotStarLed.o ./src/Fans/Fan.o  ./src/Endstops/Endstop.o ./src/Endstops/EndstopsManager.o ./src/Endstops/ZProbe.o ./src/Endstops/ZProbeProgrammer.o  ./src/DuetNG/DueXn.o ./src/DuetNG/Pins_DuetNG.o ./src/DuetNG/SX1509.o  ./src/Display/ST7920/glcd11x14.o ./src/Display/ST7920/glcd7x11.o ./src/Display/ST7920/lcd7920.o  ./src/Display/Display.o ./src/Display/Menu.o ./src/Display/MenuItem.o ./src/Display/RotaryEncoder.o  ./src/CAN/CanInterface.o ./src/CAN/CanMessageGenericConstructor.o ./src/CAN/CanMotion.o ./src/CAN/CommandProcessor.o  ./src/Logger.o ./src/OutputMemory.o ./src/Platform.o ./src/PortControl.o ./src/PrintMonitor.o ./src/RepRap.o ./src/RepRapFirmware.o ./src/Roland.o ./src/Scanner.o ./src/SoftTimer.o ./src/Tasks.o   -lCoreNG -lCoreNG -lFreeRTOS -lRRFLibraries -Wl,--end-group -lm
/opt/x-tools/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: ./src/RepRap.o: in function `RepRap::GetStatusCharacter() const':
RepRap.cpp:(.text._ZNK6RepRap18GetStatusCharacterEv+0x26): warning: undefined reference to `Platform::HasVinPower() const

Could you update us on which branches of the various projects currently go together for the Duet2 and Duet3 and which configurations go together for the Duet3 as I can't get that to build either.

Also, there's a typo in src/Heating/RemoteHeater.cpp
#include <CanMessageformats.h> should be
#include <CanMessageFormats.h>

NoSkillzEngineer

@grizewald Hmmm, I didn't know that about the comments and content. I also was not considering the retrieval of information or the storing of it, I was thinking purely communication specific. I use Swype for my phone and there is no way I can type faster on a keyboard, no way. A phone, specifically an android one, also utilizes Google's Talk-To-Text which you can more or less speak normally and it'll beat most far typers with minimal errors in most dialects, with exceptions of course. Just a quick thought, I don't care to go into chrome and logon each time and go to the website specifically to go into the forum. Their own app (built with flutter) could also be an alternative. ¯_(ツ)_/¯

grizewald

@noskillzengineer said in New RepRapFirmware 3.0 early beta:

@grizewald Hmmm, I didn't know that about the comments and content. I also was not considering the retrieval of information or the storing of it, I was thinking purely communication specific. I use Swype for my phone and there is no way I can type faster on a keyboard, no way. A phone, specifically an android one, also utilizes Google's Talk-To-Text which you can more or less speak normally and it'll beat most far typers with minimal errors in most dialects, with exceptions of course. Just a quick thought, I don't care to go into chrome and logon each time and go to the website specifically to go into the forum. Their own app (built with flutter) could also be an alternative. ¯_(ツ)_/¯

I use a keyboard all day long and can type 120 words per minute, so predictive text input is still slower for me. I can't bring myself to sit talking to an inanimate object and I'd look pretty stupid doing that in front of other people.

dc42

@gtj0 said in New RepRapFirmware 3.0 early beta:

@dc42 Just FYI... The current v3-dev RRF branch isn't building for the Duet2...

Could you update us on which branches of the various projects currently go together for the Duet2 and Duet3 and which configurations go together for the Duet3 as I can't get that to build either.

Also, there's a typo in src/Heating/RemoteHeater.cpp
#include <CanMessageformats.h> should be
#include <CanMessageFormats.h>

Now fixed. For RRF3 use the v3-dev branch of RepRapFirmware and the dev branches of everything else (except CANlib which doesn't have a dev branch).

gtj0

@dc42 Homing still seems to be an issue as well as the "slightly off" home positions.

wilriker

@dc42 said in New RepRapFirmware 3.0 early beta:

@gtj0 said in New RepRapFirmware 3.0 early beta:

Also, there's a typo in src/Heating/RemoteHeater.cpp
#include <CanMessageformats.h> should be
#include <CanMessageFormats.h>

Now fixed. For RRF3 use the v3-dev branch of RepRapFirmware and the dev branches of everything else (except CANlib which doesn't have a dev branch).

T~~he case-issue is still not fixed in latest v3-dev branch (I also sent a Pull Request a couple of days ago)~~. EDIT: That was an issue with not correctly fetching the latest changes.

More problematic for me is that I cannot build RRF 3 for DUET3_V05 (or DUET3_V06). It bombards me with linker errors:

/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `prvIdleTask':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:3266: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `prvAddCurrentTaskToDelayedList':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4929: warning: undefined reference to `portRESET_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `prvAddNewTaskToReadyList':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:1084: warning: undefined reference to `portRECORD_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:1096: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `vTaskDelete':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:1125: warning: undefined reference to `portRESET_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:1190: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `xTaskIncrementTick':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:2676: warning: undefined reference to `portRECORD_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `xTaskResumeAll':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:2134: warning: undefined reference to `portRECORD_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:2196: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `vTaskDelayUntil':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:1275: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `vTaskDelay':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:1320: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:1320: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `vTaskSwitchContext':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:2896: warning: undefined reference to `portGET_HIGHEST_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `vTaskSuspend':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:1646: warning: undefined reference to `portRESET_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:1699: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `xTaskRemoveFromEventList':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:3009: warning: undefined reference to `portRECORD_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `xTaskPriorityInherit':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:3834: warning: undefined reference to `portRESET_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:3843: warning: undefined reference to `portRECORD_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `xTaskPriorityDisinherit':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:3933: warning: undefined reference to `portRECORD_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:3917: warning: undefined reference to `portRESET_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `vTaskPriorityDisinheritAfterTimeout':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4042: warning: undefined reference to `portRECORD_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4035: warning: undefined reference to `portRESET_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `ulTaskNotifyTake':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4433: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `xTaskGenericNotify':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4619: warning: undefined reference to `portRECORD_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4644: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(tasks.o): in function `vTaskNotifyGiveFromISR':
/home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4818: warning: undefined reference to `ulSetInterruptMaskFromISR'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4839: warning: undefined reference to `portRECORD_READY_PRIORITY'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4870: warning: undefined reference to `vClearInterruptMaskFromISR'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/tasks.c:4870: warning: undefined reference to `vClearInterruptMaskFromISR'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(queue.o): in function `xQueueGenericReset':
/home/manuel/github/FreeRTOS/SAME70/../src/queue.c:274: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(queue.o): in function `xQueueGenericSend':
/home/manuel/github/FreeRTOS/SAME70/../src/queue.c:901: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/queue.c:767: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/libFreeRTOS.a(queue.o): in function `xQueueSemaphoreTake':
/home/manuel/github/FreeRTOS/SAME70/../src/queue.c:1538: warning: undefined reference to `vPortYield'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: /home/manuel/github/FreeRTOS/SAME70/../src/queue.c:1450: warning: undefined reference to `vPortYield'

gtj0

@wilriker said in New RepRapFirmware 3.0 early beta:

@dc42 said in New RepRapFirmware 3.0 early beta:

@gtj0 said in New RepRapFirmware 3.0 early beta:

Also, there's a typo in src/Heating/RemoteHeater.cpp
#include <CanMessageformats.h> should be
#include <CanMessageFormats.h>

Now fixed. For RRF3 use the v3-dev branch of RepRapFirmware and the dev branches of everything else (except CANlib which doesn't have a dev branch).

T~~he case-issue is still not fixed in latest v3-dev branch (I also sent a Pull Request a couple of days ago)~~. EDIT: That was an issue with not correctly fetching the latest changes.

More problematic for me is that I cannot build RRF 3 for DUET3_V05 (or DUET3_V06). It bombards me with linker errors:

Yeah same here .

martink

The SAME70 configuration include paths for FreeRTOS include src/portable/GCC/ARM_CM0. Changing that to src/portable/GCC/ARM_CM7/r0p1 helps. I haven't tried using the resulting firmware binary.

wilriker

@martink Thanks for spotting that! This fixes linker errors. And it flashs fine so far.

dc42

@martink said in New RepRapFirmware 3.0 early beta:

The SAME70 configuration include paths for FreeRTOS include src/portable/GCC/ARM_CM0. Changing that to src/portable/GCC/ARM_CM7/r0p1 helps. I haven't tried using the resulting firmware binary.

Thanks, fixed in latest commit.

gtj0

@dc42 said in New RepRapFirmware 3.0 early beta:

@martink said in New RepRapFirmware 3.0 early beta:

The SAME70 configuration include paths for FreeRTOS include src/portable/GCC/ARM_CM0. Changing that to src/portable/GCC/ARM_CM7/r0p1 helps. I haven't tried using the resulting firmware binary.

Thanks, fixed in latest commit.

@dc42 Any idea on the homing issues?

dc42

@gtj0 said in New RepRapFirmware 3.0 early beta:

@dc42 said in New RepRapFirmware 3.0 early beta:

@martink said in New RepRapFirmware 3.0 early beta:

The SAME70 configuration include paths for FreeRTOS include src/portable/GCC/ARM_CM0. Changing that to src/portable/GCC/ARM_CM7/r0p1 helps. I haven't tried using the resulting firmware binary.

Thanks, fixed in latest commit.

@dc42 Any idea on the homing issues?

I'm sorry, this thread has got so long that it's difficult to track the different issues raised in it. Please start a new thread for that issue.

smoki3

@dc42 said in New RepRapFirmware 3.0 early beta:

@smoki3 said in New RepRapFirmware 3.0 early beta:
@dc42
It was definitely not like this on 2.02 and the older 3.0.

And its a really wired behaviour. Because I use:
; tfree0.g
; called when tool 0 is freed
;
; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
G91
G1 Z10 F7200
G90
G53 G1 X0 F25000 ;XPOS
G53 G1 Y190
G53 G1 Y195 F5000
M400
M98 P"/macros/Toolhead/1. Toolhead unlock"
G4 P320
G53 G1 Y207 F5000
M400
G53 G1 Y165 F25000
M400
; tpre1.g
; called before tool 0 is selected
;
; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
G1 X76 F25000
M400
G1 Y192
M400
M98 P"/macros/Toolhead/1. Toolhead unlock"
G4 P400
G1 Y207 F5000
M116 P3
M400
M98 P"/macros/Toolhead/2. Toolhead lock"
G4 P260
G1 Y150 F15000
The I only expect that only a X movement is done while the start of the tpre1.g but it first moves in X and Y.
@smoki3, I am looking into this but I need your config.g file, also the toolhead unlock files that you call from the tool change files.

I uploaded my config files and my tool changer macros:

Config:
https://drive.google.com/file/d/1xQ5j9E2WvJNFzIum62W02iligk8rOv4T/view?usp=sharing

Macros:
https://drive.google.com/file/d/1QcHqPQBpafr3AlDOjGM3XtQ7nB4VcalO/view?usp=sharing