**** BEGIN LOGGING AT Tue Jan 04 02:59:56 2022 Jan 04 03:36:21 The build is back on! Workin' and workin' to get this daughter card, the Cape, up and out! Jan 04 03:37:38 First, w/out mcu and then...dun, dun, dun, dun. W/ mcu! Jan 04 07:42:18 zmatt, yes now that i got it almost working like this, i'll probably polish the solution though. It involved modifying the library. This device works well with other monitorings, i'll see what manufacturer said about it. Jan 04 09:38:33 zmat, right, indeed it must not be the modbus spec, it was said to me the device was plugged into a box and properly read. Jan 04 09:39:27 zmat, That explains why I had so much trouble making libmodbus work, indeed the default lib. has a parameter for rts which is quite long, that is coherent with the 3.5 char silent. Jan 04 09:56:11 I can confirm, the device responds immediately after the request.50 microseconds or less Jan 04 09:56:58 That's on boot, single modbus request, first request+response, no possible frame error. Jan 04 10:31:36 Yes! Jan 04 10:32:02 Give it to 'em, jfsimon1981. Shoe that modbus up! Jan 04 10:32:16 For instance... Jan 04 10:32:26 * set_ is a cheerleader to the electronics field for now! Jan 04 10:37:48 How you say, lemme learneth moreth! Jan 04 10:38:00 Sorry. Off to dabble. Jan 04 10:39:11 jfsimon1981: 50 microseconds measured from where exactly? I do hope from the end of the last stop bit and not from the last rising edge (which is at the latest between the parity bit and the stop bit) Jan 04 10:40:25 though either way that's insanely short, that's barely a bit-time Jan 04 10:41:08 jfsimon1981: I'm honestly surprised this would work with other modbus masters, given how seriously it violates the spec Jan 04 11:05:07 i understand they respond as soon as the frame is received in full as you said. Jan 04 11:06:04 That and possible the rs485 needs a ground ref although it should not, are - apparently - what cost me 4 weeks delay ! 2 weeks to just understand why the lib modbus did'nt work and 2 to found a way around. Jan 04 11:06:29 But not I'm going to implement an accurate delay in the lib, so this workaround can work reliably. Jan 04 11:07:02 what do you mean? it sounds like you want to eliminate any delay Jan 04 11:07:23 The kernel on BB has "Preempt" flag on. That can be leveraged i hope to make some part deterministic. Jan 04 11:07:51 it will probably be worse than letting the kernel handle rts Jan 04 11:07:55 I mean RTS needs to be very precise and not wander off by few us as it does not, sometime causing overlap. Jan 04 11:08:18 that requires pru or a hardware solution (rs485 transceiver with auto-driver-enable) Jan 04 11:09:14 Ye sif kernel can leverage the preempt, otherwise I think it's possible to make a specific usleep() that's not interrupted, though i might be wrong, on bbb thx to preempt (or at least better that the standard library function). i don't know yet Jan 04 11:09:30 if using kernel control of rts is not stable enough (using a non-RT kernel may actually be more reliable than an RT kernel for that) Jan 04 11:09:36 as you mentionned PRU could be leveraged although i'm verty late on this project now ... Jan 04 11:10:01 why are you still talking about usleep? I don't get what you're doing Jan 04 11:10:09 and no, you will get interrupted regardless Jan 04 11:10:21 since the kernel needs to service the uart interrupts Jan 04 11:10:45 which is why allowing the kernel to manage the rts should always be better than doing it in userspace Jan 04 11:12:00 libmodbus uses it, and the frames somethime collide due to the way the library implements rts. Jan 04 11:12:15 I remind the same happened with letting kernel do. Jan 04 11:12:16 sounds like it just sucks Jan 04 11:12:23 don't know Jan 04 11:12:47 have to make a few tests Jan 04 11:13:12 had the probe been implementing this a little better ... anyway. Jan 04 11:13:36 honestly, if you really have only one bit-time of turnaround time, I seriously doubt you'll ever get this working properly in linux Jan 04 11:13:57 (and from your description it still isn't clear to me whether you even have that much or whether that 50 us is the stop bit) Jan 04 11:13:59 i have hope Jan 04 11:14:17 can be a little tough but possible i guess Jan 04 11:14:25 I sincerely doubt that Jan 04 11:14:26 joker is the pru at th emoment Jan 04 11:14:28 not reliably Jan 04 11:15:03 if you want an easy fix without having to learn to deal with pru, use the hardware solutionI mentioned Jan 04 11:15:11 or find a modbus device that isn't broken Jan 04 11:15:21 or get the manufacturer to fix their broken device Jan 04 11:17:03 client device Jan 04 11:17:25 server (slave) device you mean? I thought the bbb was the client (master) Jan 04 11:17:40 very specific, we can do nothing about this, it has modbus but also a chemical something converter Jan 04 11:17:53 client = customer Jan 04 11:17:57 ohhh Jan 04 11:18:02 that makes more sense Jan 04 11:18:02 the customer probe (which is a slave) Jan 04 11:19:19 so have them fix it... can't be that hard to at least insert that 3.5 bit-time delay (which still wouldn't make it behave according to the modbus spec, but would at least make it not insane to deal with) Jan 04 11:19:29 before sending a response Jan 04 11:19:33 is something very small that i have to read from however this takes me, but the master has more jobs to do hence a linux bb is more a less required. Doing logs, usb writes, little bit passed the edge of what microcontroller alone could do. Jan 04 11:20:16 sure, the problem I think this device is implemented in many other oems products so making them to change it, might be possible, Jan 04 11:20:30 i asked them about this issue, no response yet Jan 04 11:20:31 ughhh Jan 04 11:20:57 so they made a hot mess and then made it your problem Jan 04 11:21:10 honestly i doubt i get too much support, so i'll work around Jan 04 11:22:17 yep i assume many other people have figures out and got it work anyway, or maybe did'nt see the issue because the specific way they implemented, more hardware solution without embedded os. Jan 04 11:22:51 still sounds odd to me, normally you'd still have some turnaround time Jan 04 11:23:02 cant' request my customer to pay for this troubles ... Jan 04 11:23:40 i'll explain to the customer, he's comprehensive at the moment Jan 04 11:25:14 i'll post some pix so you can see what'shappening Jan 04 11:40:28 Me too? Can I see? Jan 04 12:16:33 Here's the link Jan 04 12:16:33 http://jean-francois-simon.com/share/modbus/2022-01-04_Tests.zip Jan 04 12:17:17 i'd be interested to have your point of view on those frames ... Jan 04 12:18:05 Hardware layer RS-485, protocol Modbus-RTU, 19200 baud, 1 start bit, 1 stop bit, no parity bit. Jan 04 13:55:13 behaves worse with the busy timer, tough issue. Jan 04 13:55:39 (busy timer is more accurate but keeps cpu busy). Jan 04 16:24:35 zmat, kind of working on uart with rts support, seems to be better that the modified lib in user space. Thanks for this hint, I ruled this out a few weeks ago but i certainly had another issue back then. It's running seems about right. Jan 04 16:25:21 Will leave it running the com test for a few hours. A few time out and crc errors reports, might acceptable. Jan 04 19:09:05 I made it back after cleaning up sticks! Here is my sign? Jan 04 19:09:17 Oops. Wrong room. Jan 04 19:09:18 BBB! Jan 04 19:10:18 Things are working out for the AI so far. I erased everything on my SD Card and now I am rebuilding so slowly! Wish me luck? Jan 04 19:10:41 tflite and opencv w/ python at the helm! Jan 04 19:41:16 wow... ´[´ is actually an executable. Cool. Jan 04 21:49:01 okay, what's the latest 2GB flasher image for bbb? Jan 04 21:49:34 am i supposed to use something like this? https://rcn-ee.com/rootfs/bb.org/testing/2022-01-01/bullseye-minimal/am335x-debian-11.2-minimal-armhf-2022-01-01-2gb.img.xz **** ENDING LOGGING AT Wed Jan 05 02:59:56 2022