**** BEGIN LOGGING AT Fri Sep 30 02:59:57 2022 Sep 30 08:43:55 zmatt, good morning, yes it turns out two types of devices i checked and interface to do not wait. It is my opinion this part of the standard is not applied in most recent devices. Sep 30 08:44:12 Although i have checked only two from US and Chinese manufacturers. Sep 30 08:45:36 The uart if properly handled at hardware level, which i trust since it has IRQs, should not be handled by the processor and it should be buffered. If so there shouldn't be much issues. Sep 30 10:06:55 jfsimon1981: asserting and deasserting rts is still done by software, albeit by the kernel in an interrupt handler Sep 30 10:08:10 jfsimon1981: and the delay before responding is an absolutely required part of the modbus protocol, in fact the way the end of a message is indicated is through a transmit idle period (which can, necessarily, only be detected by waiting) Sep 30 10:08:49 sending a reply without this delay means the reply is sent before the request message has officially ended Sep 30 10:13:12 yes correct, it should be at interrupt level hence the interrupt priority question for sure, this can happen Sep 30 10:13:19 (minimum gap required between end of request and start of reply is 2ms if the baudrate is 19200) Sep 30 10:14:42 i believe the library can work all right with the standard stop pause Sep 30 10:15:12 (500us should be the default wait time to toggle rts back in the lib itself) Sep 30 10:15:24 the lib doesn't control rts, the kernel does Sep 30 10:15:59 by default there's no wait time, it just deasserts rts once the transmission is complete Sep 30 10:17:09 What happened is that it kept RTS active too long, hence devices talked on a busy line, and that did'nt work both because drivers interfere, and receive is disabled, hence RTS really needs to get off at the instant transmission finished. I saw they again yesterday on the scope, all happens right at the edge of a frame. Sep 30 10:17:39 right, because the device is broken and violates the modbus specification Sep 30 10:17:50 Yes now it does, before, i still handled throught the library although it needed fine tune per device type. That could be possible only during developemnt. Sep 30 10:18:04 Yes, i don't know how widespread this is Sep 30 10:18:19 be sure to report the bug if possible Sep 30 10:18:41 i can for sure, at least p Sep 30 10:18:50 peeke the question to manufacturer, 2 of them Sep 30 10:21:52 for baudrates up to 19200 the line must be idle for at least 38.5 bit-times (e.g. 2ms @ 19200, 4ms @ 9600), for higher baudrates the line must be idle for 1.75ms before sending a reply Sep 30 10:22:17 (more generally, this delay is required between any two messages on the bus) Sep 30 10:23:43 yes i remind we discussed on this too, that's quite tricky, if hardware aren't harmonized Sep 30 10:24:22 Both with which i dealt responded quicker but not the same, us ones has a longer delay Sep 30 10:24:32 it's just a protocol violation, a misimplementation of modbus Sep 30 10:25:58 it also implies deeper problems in how their code works, since on modbus rtu this minimum idle time is the _only_ way to determine the end of a message (and obviously you need to detect the end of a message before sending a reply) Sep 30 10:26:36 idle time is what marks the completion of a transmission Sep 30 10:27:15 I'm not finished yet, i had to "reboot" the library, since sometimes, the client/host messages get back wrong, that can put the modbus library into a state when it never recovers. Hence at the moment, for each frame, i fully initialyze it. It's more complicated but reliably works. If i get time for it, i'd like to integrate a reinit where this gets messed at library level, so it does'nt neet to be instanciated every Sep 30 10:27:15 time. That's another todo item. Sep 30 10:28:16 I think the "state machine" in the library handles that rather than timing though i didn't check deeply how that works yet. Sep 30 21:49:24 I have a BBBW at a remote location where only the Power LED lights up on application of power, nothing else happens. No USR LEDs flashing etc. I usually run it off of a microSD card and tried with and without. If you have any suggestions for troubleshooting, please let me know. Thanks! Sep 30 22:07:21 I found a RS232 header cable and was able to plug it into the pins and get some info! https://pastebin.com/Y7Whay6g looks like it's not able to find the flash info on the microSD card. **** ENDING LOGGING AT Sat Oct 01 02:59:56 2022