So after going through all the code, i notice i dont need an extra variable to save target temp into. It seems reprap object has its on gettargettemp/getactivetemp within itself. After implementing just one line of code like this:
targettemp = reprap.GetHeat().GetTargetTemperature(i); // i is the heaternumber
I was able to read the active and standby temperatures just fine. I'm writing here this so that if anyone needs help regarding the issue can see it.
Thank you all for reading!
So after going through all the code, i notice i dont need an extra variable to save target temp into. It seems reprap object has its on gettargettemp/getactivetemp within itself. After implementing just one line of code like this:
targettemp = reprap.GetHeat().GetTargetTemperature(i); // i is the heaternumber
I was able to read the active and standby temperatures just fine. I'm writing here this so that if anyone needs help regarding the issue can see it.
Thank you all for reading!
Hello everyone!
I need help with a small problem that I'm facing in my development project. I'm trying different methods and approches to overcome the problem but I haven't achieved to find a workaround yet and it's probably due to my lack of knowledge regarding DuetFirmware.
About my project:
I have STM32 nucleo board and I'm using it as a full duplex SPI slave to communicate with my Duet3 MB6HC board. I want to send temperature data to my Duet board that i generated on my Nucleo and in the meantime i want to get target temperature data that i typed in on Duet-Webserver.
What i did so far:
I customised the ThermocoupleSensor31856 code in RepRapFirmware according to my needs and assigned my nucleo board as a heater to my tool. Currently i send temperature data to my Duet board and so far i can see the temp data on Webserver without a problem. But I want to read the target temperature from Duet board (Active or standby mode doesn't matter). Since i don't want to change the structure of the firmware so much, i want to keep everything in my customised Thermocouple class, if It's possible.
ThermocoupleSensor31856 has Poll() function in it and it's been used for sending and receiving data from the sensor. I use this command below to send data to Duet board.
static uint8_t dataOut[4] = {0x0C, myTargetTemp, targettemp_a , targettemp_b}; // myTargetTemp is the data i want to get from Duet and send over SPI
TemperatureError sts = DoSpiTransaction(dataOut, ARRAY_SIZE(dataOut), rawVal);
As simple enough, rawVal is what i receive from Nucleo board and dataOut is the array i send to Nucleo over SPI. After this, things get complicated.
i debugged and analysed the firmware as much as i can, and found couple of functions in which i can get the target temperature.
So far the best candidates that i can extract target temps are: Tool.cpp, Heat.cpp. and Reprap.cpp
I tried to do the same or similar ways to get the temp information just like how it is done in ReportToolTemperatures and SetToolHeaterActiveOrStandbyTemperature but no luck so far.
void RepRap::ReportToolTemperatures(const StringRef& reply, const Tool *tool, bool includeNumber) const noexcept
{
Doing Something...
Heat& heat = reprap.GetHeat();
char sep = ':';
for (size_t i = 0; i < tool->HeaterCount(); ++i)
{
const int heater = tool->GetHeater(i);
reply.catf("%c%.1f /%.1f", sep, (double)heat.GetHeaterTemperature(heater), (double)heat.GetTargetTemperature(heater));
sep = ' ';
}
}
}
I also try to get the target temp value in Tool (since i just have 1 tool heater and 1 bed heater). I initiliased a public variable called myTargetTemp(in Tool.h) and implemented it like this:
void Tool::SetToolHeaterActiveOrStandbyTemperature(size_t heaterNumber, float temp, bool active) THROWS(GCodeException)
{
Doing Something...
if (setHeater)
{
reprap.GetHeat().SetTemperature(heater, temp, active); // This is where the target temperature is actually passed on and set.
myTargetTemp = temp; // Defined variable by me in Tool.h
}
}
}
}
Main idea was to write the targettemp (temp variable here) to my variable and call that variable in thermocouple class. But i just read "0" from my variable.
Another approach that i thought of was to implement a function like this in thermocouple class and call that function in Poll() to get the updated target variable and pass it into spi tx buffer.
void ThermocoupleSensor31856::TargetTempReceive() THROWS(GCodeException)
{
//ReadLocker lock(toolListLock); // Requires FreeRtos
size_t i = 0;
const Tool * const currentTool = reprap.GetCurrentTool();
Heat& heat = reprap.GetHeat();
if(currentTool != nullptr){
i = 0;
int heater = currentTool->GetHeater(i);
targettemp_a = (uint8_t)heat.GetTargetTemperature(heater); // my 1. variable to read
throw GCodeException(-1, -1, "I throw error here in i=0");
i = 1;
heater = currentTool->GetHeater(i);
targettemp_b = (uint8_t)heat.GetTargetTemperature(heater); // my 2. variable to read
throw GCodeException(-1, -1, "I throw error here in i=1");
}
}
GCodeExceptions are there to understand if the currentTool is initialised or not because i was getting again zeros. And i noticed currentTool pointer was always a nullptr. There is definetly something here that i cannot get the addresses from GetCurrentTool() function.
One other thing: I tried to implement something like this in Poll() function:
targettemp_a = (uint8_t)reprap.GetCurrentTool()->GetToolHeaterActiveTemperature(i);
But with this line unfornately, whenever Duetboard tries to start up, the spi communication restarts itself and forces the board to initialise/boot up again and again.
This is all i tried so far, except for small things here and there.
Anyways, I tried to explain everything as much as possible. I hope it's enough to give you a rough idea what I'm trying to do. I can provide you with more information if it's needed. But from what i experienced, Im guessing I'm forgetting something very obvious in regard to firmware itself. Maybe forgetting something about pointers or maybe messing with the Rtos in a bad way but im out of ideas for now.
If there is a way or a workaround that i can use, it would be a great help!
@dc42 Hello!
Thank you for the quick reply. Unfornately, i was still not be able to build the project with the suggested way. I tried everything to set the make path to my directory where make.exe lies but it threw errors after errors eventhough the path parameter was correct.
BUT i found the solution by uninstalling and installing the ARM Eclipse Tools. This time i didn't have any space or blanks in my install directory. eg: "C:\ARMEclipseTools\2.6-201507152002\bin"
And this way it worked like a charm! Although i had lots of errors regarding wifisocket module, it built duet3 bin file. I loaded it on my duet3 board to see if it's working and there seems to be no problem so far.
Thanks for the help!
Hello everyone!
I'm kinda new with Duet3d compiling/building process and I'm currently having a problem with v3.4 on Eclipse C/C++(Windows) with the Duet3 board configuration.
I followed all the steps on this page: https://github.com/Duet3D/RepRapFirmware/wiki/Building-RepRapFirmware
The problem is as follows:
**** Incremental Build of configuration Duet3_MB6HC for project RepRapFirmware ****
make -j16 all
c:/program files/gnu arm eclipse/build tools/2.6-201507152002/bin/sh: C:/Program: not found
makefile:98: recipe for target 'all' failed
make: *** [all] Error 127
"make -j16 all" terminated with exit code 2. Build might be incomplete.
Build Failed. 2 errors, 0 warnings. (took 1s.34ms)
It fails on this commandline:
all:
+@$(MAKE) --no-print-directory main-build && $(MAKE) --no-print-directory post-build
and the screenshots regarding the issues:
I was suspecting that maybe I had some problem with the make tool. But make, rm and sh seem to be in right place.
Im also using the suggested Arm Toolchain on Eclipse to compile the firmware. Nevertheless it gives me the same error only on ReprapFirmware building. The make building of other modules seems ok.
I'm really struggling to solve the issue for 2 days now and I tried most of the suggestions that i found on the internet and the forum. I'm out of ideas to proceed further. I'm open for all workarounds.