Topics created by pjl

Python has a debugger , which is available as a module called pdb . It supports setting conditional breakpoints , stepping through the source code one line at a time, stack inspection, and more.

import pdb msg = "this is a test" pdb.set_trace() print(msg)

Insert pdb.set_trace() anywhere and it will function as a breakpoint . When you execute the script by python test.py, you will in the python debug mode.

Can anyone explain why the parameters do not get executed when using the perform_code() method? This is the only way I managed to get this to send successfully:

from dsf.connections import CommandConnection from dsf.commands.code import Code from dsf.commands.code import CodeFlags from dsf.commands.code import CodeType from dsf.commands.codeparameter import CodeParameter def send_code(): command_connection = CommandConnection(debug=True) command_connection.connect() instance = Code("Code") instance.Type = CodeType.MCode instance.MajorNumber = 106 instance.parameter = CodeParameter('S', 255) instance.Flags = CodeFlags.Asynchronous

It sends, responds with success, but nothing happens, fan speed does not change, but commands with no parameter work fine, such as G28, or T0 etc.

send: {"command":"Code","Type":"M","MajorNumber":106,"parameter":{"letter":"S","string_value":"255","_CodeParameter__parsed_value":255,"is_expression":false},"Flags":1} recv: {"success":true}

@mendenmh Thanks for the input, you're absolutely correct about emissivity issues. In this case though, I'm more interested in filament temperatures rather than the nozzle. I will still be doing emissivity corrections on the data. And calibrating a thermistor to an IR sensor reading is quite funny 😁

@chrishamm I have the same concerns about safety, and agree that adapting RRF is the proper way to go. The problem being, that with my lack of C++ chops, when I started going through the source, I got quite intimidated 😓 (honestly it looks like I just wont manage to fit in my time budget, I am hesitant to bother people too much here about this)
If I made a new sensor type, can the data be obtained through the ribbon cable SPI bus or is it too busy and I would still need connect a free SBC GPIO output to an input connector on the Duet? e.g. SBC SPI out -> SPI on the Duet's temperature daughterboard connector (then I suppose in that case I need to hijack the spiTemperatureSensor.cpp, is that all that I would need to mess about with? )

Im not sure I understand what you mean by "configure heater output as a servo pin"
you suggest having my SBC script send M280 commands through dsf-python and then configure OUT_1 as a servo output? If so, cool, didnt know thats possible. Would consider as dubious plan B 😅

Thanks for the comments

@pjl If you have .ssh files or directories in your user profile's directory, try moving/deleting them. Perhaps that will fix it.

@pjl said in RRF Config Tool suggestion: a notification which FW is provided:

@phaedrux apologies for the wrong section

Not a problem.

Q1: yes (probably)

I use the Pi other SPI bus for driving a string of APA102 LEDs. I'm driving the bus at 10 MHz. Since it's the only SPI device I have on that bus, I don't have a CS line connected. Also it's one-way comms (nothing coming back into the Pi) so I don't use a MISO. Accordingly I just use pins 38 & 40.

So it works for me, but my situation is simpler than yours is likely to be.

@pjl you should be able to use the standard IAP binary, assuming that you haven't modified the IAP functionality in your fork of RRF. The IAP is built from a separate Eclipse project, DuetIAP.