Posts made by gloomyandy

@Notepad That may or not be a good idea, I know that with the stm32 fork (that I look after), interim builds are not always for general use (they often contain experimental fixes and/or additional debug checks etc). Also the time needed to produce/document/test a full release build is quite considerable so I suspect that is why the Duet folks do not post the full details.. So if you do use an interim build use it with care (even more so than with a "beta release") and don't be too surprised if you hit problems, if you do hit a problem it is probably worth reporting it though.

@Argo That's a little odd you can't normally move an axis when it has not been homed.

@Notepad B2+3 is not an "official release" it is a test build for a particular problem. Those changes (which may not be complete) will probably end up (and be documented) in 3.6.0-beta.3

@Argo Can you provide more information about what exactly you are doing to generate this error. So for instance is the machine homed before you issue those commands? How exactly are you issuing the commands (gcode via the console, using DWC jog commands etc?)?

Ideal would be a short gcode file that you can run that demonstrates the problem. Ideally the gcode command could be run when the printer has just been powered on.

@TomW Probably worth posting your config.g file and the details of the type of probe you are using. Seems a little odd to be getting that error with a M280 operation (which moves a servo). What sort of probe operation are you doing when this happens? If when homing Z might be worth posting your homez.g file as well.

When did this problem start to happen? Was it working ok at some point?

@NineMile I've merged and pushed David's changes to the stm32 repos. I don't currently have a modbus setup so have not been able to test either the old or new code.

@NineMile I'm also planning to be at SMRRF, probably on the Sunday.

@dc42 I had a quick look at the linuxCNC HAL code for the VFD that the user over on discord was using. That looks like it uses the same crc16 and seed as modbus but has a different payload. I get the impression from a quick scan of the linuxCNC stuff that this is fairly common, devices which claim to be "modbus" use the modbus signal timing. framing and crc but do not use the modbus register/coil model and associated commands. But I'm certainly no expert on this.

@NineMile said in Modbus Spindle Control:

Edit: I don't think status checks can be optimised to only check after commands. Imagine if you start a spindle and then run a 10 min machining op, and 8 mins in the VFD overheats and shuts down. RRF wouldn't know about that and could potentially keep running the toolpath while the spindle is stopped, which would cause all sorts of issues including potential broken tools. I do think the status checking needs to be running at all times while a spindle is running.

As I said above I'm not a big fan of using modbus for serious errors, personally I'd say you should be using some sort of trigger from a hardware fault signal for that. But even in this case I suspect that the reality is that a second (or possibly) more would be fast enough to handle that situation.

My thoughts on checking for a response after a command was that perhaps you can use a slower polling rate during "normal operations" and only increase that rate if you need to after say issuing a command. But really that is just detail and probably depends a lot on the actual use case.

I'm curious in the table above, it lists a "start" value, but I don't see any mention of that either in the spec I linked to or the code. Where is that table from?

@NineMile said in Modbus Spindle Control:

f you discount CRC, the only real difference between the Modbus gcodes and the UART gcodes is that the Modbus ones restrict the functions that can be called. It might make more sense to add a CRC option to the UART commands and let the caller build the packet contents in whatever fashion they want rather than having commands specifically for modbus-rtu.

I don't think that is really the case. If you take a look at the modbus write funtion here: https://github.com/Duet3D/RepRapFirmware/blob/3.6-dev/src/Comms/AuxDevice.cpp#L190

You will see there are extra calls around the actual write operations. My understanding is that these work with the low level UART code (in coreN2G) to ensure that the modbus data is written as a single "burst" of bytes (avoiding possible issues with task switches between writing bytes) and that there is a sufficiently long period of "no data" between packets (in effect modbus uses no data as a packet delimiter). None of that is present in the standard UART write code (this is what my comments about "timing" referred to above). Oh and there is also the handling of the RS485 transceiver read/write pin which is needed if that does not do auto switching. So at the very least we would need to identify if the UART is in "modbus" mode or not. There is then also the handling of "read" operations which are really a write followed by a read, again I think that this has timing considerations that don't really apply to the normal UART read.

So I think there might still be a case for having modbus specific read/write operations but I'd be tempted to try and make them more generic ones that simply read/write a bunch of bytes and apply the timing and crc to them, but leave the formatting and decoding of those bytes up to the user in the form of a script?

That's my take on this, I'd be interested to hear @dc42 take on the matter. To help with that, do you have any feel for how often spindle commands are actually issued and what sort of polling might be needed for status reporting? Can this status polling perhaps be optimised by for instance only doing some of it immediately after issuing a command?

@NineMile I guess the question is how often do you actually need to issue spindle control commands and how often do you actually need to read data from the spindle? Unless there is some sort of closed loop control going on I would hope the answer would be not very often. Even with the reads being handled by daemon.g I would hope that if there is a loss of communication you could raise an event. if there is some sort of safety issue here that needs a fast response I'm not sure that handling that via modbus is a very good solution. Don't these devices typically have some sort of "alarm" function/signal that can be hooked up to an input pin?

I don't really like the idea of having some sort of "HAL" built into RRF, it makes adding support for new devices much harder and adds extra code (so more flash space and stuff to maintain), that has zero benefit for the majority of RRF users.

An interesting question is that if we went this way should we keep the existing modbus gcode commands (that handle the various register/coil commands) or drop them and simply have a modbus read/write command that does the minimal framing (timing + <packet content> + crc) and leave it up to scripts to construct the "packet content"? At the moment we only support a subset of the modbus-rtu commands listed in this document: https://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf so the current implementation may need expanding?

@NineMile Would this work with the VFD discussed over on discord (the HY02D223B I think)?

Personally I'd prefer to extend RRF via external scripts to handle the various spindle operations. I don't think changes in speed or other spindle changes happen so often that doing this would be an issue. So basically have RRF call out to a script (with parameters if needed) for every spindle operation (start, stop, change in speed etc). I'd pair that with adding/extending the existing modbus read/write commands to offer a way to write just a set of bytes with modbus framing and crc. Looking at the LinuxCNC source it seems there are a number of VFDs (like the HY02D223B) which seem to use modbus like communication (including the "normal" modbus crc calculation), but which do not follow the register/coil model of modbus-rtu. So maybe having a way to read/write an arbitrary set of bytes with the required framing and crc would allow scripts to handle the protocol formatting? One advantage of this approach is that in theory you could use the same mechanism to talk to a VFD that does not use modbus style packets at all (though this would require any crc to be calculated by the script).

@Hernicz Is there any reason why you can't have an empty unload.g file and then perform both the unload and load operations from the load macro?

@marioys97 said in DHT22 on Duet3 Mb3HC:

M308 S5 P"1.io0.out" Y"dht22" A"Filament Temp" ; define DHT22 temperature sensor
M308 S6 P"S5.1" Y"dhthumidity" A"Filament Hum[%]" ; Attach DHT22 humidity sensor to secondary output of temperature sensor

If you run those two lines in the console do you get any sort of error?

@developeralgo222 You need to do it at various different pressure readings so we can see what the transfer function of the level shifter looks like.

@developeralgo222 Have you actually measured the voltages on each side of the level shifter you are currently trying to use? That is really the first step and should be easy to do.

@developeralgo222 I would have a thought that a voltage divider would be fine for this sort of application (reducing the range of an analogue voltage), after all that is exactly what is used to measure the supply voltage on a Duet board. Do you have a reference that gives details as to why a divider would not work?

@wschadow Are you running in standalone or SBC mode?

@developeralgo222 Have you measured the input and output voltages at the level shifter? So the analogue in signal and the corresponding shifted voltage? What are they at say 0, 40 101 KPa? I'm not sure that device is intended to operate in the way you are using it, from the datasheet "The TXS0108E device is a directionless voltage-level translator specifically designed for translating logic voltage levels.". Not sure it is intended to convert an analogue signal that varies over a entire range.

@Alva I think the first step will be to wait for 3.6.0-beta.2 (due shortly I think) and test again with that. If it still fails then try and create a simple test case that recreates the problem and then we will need to try and reproduce the problem.