Matt_AM Posted May 13, 2021 Report Share Posted May 13, 2021 Hey fancy folk, I've been looking into the DQMH architecture a bit and I'm thinking about designing a test around it. Basic test background, I am have a motor driving another motor and I'll be reading and writing over CAN for both motors and reading an analog in. I have laid out the basic module diagram as far as who is requesting what and who needs to broadcast their data. I'm currently running into 2 issues that I'm someone can provide some insight on. First Issues - constant broadcast helper loop I will be have 3 read loops broadcasting their data to an "XY Module" (the data will get formatted in the XY style and stored in a circular buffer) which the XY module will broadcast the circular buffer to the "Main Module". My issue is how do I do the constant read properly? I have 2 basic ideas. First is to create a helper loop that is started from the MHL and that helper loop continually broadcasts the message. Second is to use the MHL timeout to do my read (set the timeout from -1 to say 100ms once the module is started). IIRC, best practice is to have the helper loop do your repetitive actions, but by having my helper loop broadcast, I feel like I'm taking away from the main design that the MHL is supposed to broadcast. I am currently leaning towards the second option since I'm not too worried if my read is a bit of. For example, say another action got sent to the MHL (request sent to EHL which sends action to MHL) and the action takes 10 ms, the timing should be: read, wait X of 100 ms for MHL to receive action, do action in 10 ms, timeout 100 ms, read. This would result in a 110+X ms between the reads. I'm not worries about the 10+X ms between reads since my "test cycle" is on the side of 6 seconds. I'm just trying to make sure I understand the drawback of method 2. Second Issue - prevent circular messaging I was reading about the best practices and they were saying that modules shouldn't have circular referencing. In my project, I was going to have a set up of module A requests module B who broadcasts back to A and requests module C who broadcasts back to A. I could go into more of the specifics if you want, but this is the basic idea. Instead what I'm thining about is s Module A requests Module B, Module B broadcasts back to Module A, Module A sees the broadcast and sends the request to Module C. In this scenario, Module A seems more like a "post office" for the messages/user events being sent back and forth. I think its a bit cumbersome, but I also like how all the module controls stems from the "post office" since the submodules will only get their requests from the main module. Any additional insight would be much appreciated, Matt Quote Link to comment
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.