Recent Posts

21

General Discussion / Re: Ethernet Failure - BRX Stops Communicating

« Last post by BobO on January 27, 2023, 02:40:14 PM »

Help. I am ready to pull BRX PLCs from the field for this very reason. Very hard to get hands on the PLC when the ethernet port stops functioning after a week or a month in the middle of rural Alaska. Only a power cycle restarts comms. No one seems to have reported this problem for the last year. As far as I know I am up to the latest firmware.

The only remaining issue that we are aware of is when radios are used to talk to TCP servers (generally Modbus). We have had no reports of anything else as of the most recent firmware. Can you give me details?

As for the Modbus server issue, we're 95% sure we have a fix. We've concluded that it really isn't broken exactly, it's just that when radios misbehave (become very unreliable) is it possible for the listening socket to enter a state with a very long (20+ minute) timeout, during which the server will not accept more connections. If the client were to stop (erratically) attempting connections, eventually the timeouts clear and it starts functioning. Unfortunately, once it gets in the state, if the radio continues to be dodgy, the system won't recover and it appears that it's locked up. Once we were able to duplicate it, we were able to change the timeout behavior for that state, reducing it to 15 seconds or so. This should prevent the issue.

If that is your situation, I'm happy to give you the beta firmware to try. If that isn't your situation, then please help us understand exactly what's failing.

22

General Discussion / Re: Ethernet Failure - BRX Stops Communicating

« Last post by WRT2 on January 27, 2023, 01:50:51 PM »

After hearing more about your system from Mike, I think the beta firmware may fix the issues. Given that you are on various forms of unstable connections (radios, etc), I'm thinking you might be experiencing both of the two bugs that we've fixed. One would hang the Ethernet port totally, we think due to either the MAC hanging or due to a mismatch between the MAC and PHY, and the other that could cause an MRX/MWX to end up hung. We'll get you fixed.

Help. I am ready to pull BRX PLCs from the field for this very reason. Very hard to get hands on the PLC when the ethernet port stops functioning after a week or a month in the middle of rural Alaska. Only a power cycle restarts comms. No one seems to have reported this problem for the last year. As far as I know I am up to the latest firmware.

23

Do-more CPUs and Do-more Designer Software / Re: MEMCOPY to a Partial Structure

« Last post by franji1 on January 25, 2023, 03:26:12 PM »

maybe an STRTRIM for good measure.

Good idea.  Just verified that STRTRIM in the Sim considers NUL characters (0x00) as "whitespace", so a STRTRIM to trim trailing whitespace worked with input "abc$00$00$00$00$00" in SS0 resulted in "abc" in SS0.

24

Do-more CPUs and Do-more Designer Software / Re: MEMCOPY to a Partial Structure

« Last post by Bolt on January 25, 2023, 03:17:29 PM »

Got it. Yes, my modbus source always pads with 0x00's so it's not a big issue there. And I would force the PLC to copy 0x08 (or MyStructure.String.MaxLen) to the first 2 registers pre-copy. But now that it's chunked up into 2 instructions anyways, one for .String, one for .Parameters, it won't be a big deal to just to STRPUTB, maybe an STRTRIM for good measure.

25

Do-more CPUs and Do-more Designer Software / Re: MEMCOPY to a Partial Structure

« Last post by franji1 on January 25, 2023, 02:35:34 PM »

Realize that if you EVER change that string member length to be something other than 8 bytes (say to 16), the code that copies 0x00080008 would need to change to 0x0010010, along with better padding in your Modbus memory.  Even an UNDERFLOW would CORRUPT the memory (cuz .MaxLen would be 8, not the specified 16, making an inconsistency between what the UDT says (16) and what the actual memory says (.MaxLen member says 8) - creating confusion in some behaviors).

Moral to the story?  STRPUTB "just works".

26

Do-more CPUs and Do-more Designer Software / Re: MEMCOPY to a Partial Structure

« Last post by franji1 on January 25, 2023, 02:25:21 PM »

You have the "safest" idea of utilizing MEMCOPY for WRITING to Strings (make it fixed 0x00080008, just remember to pad).

I just tried to do MEMCOPY to a String and saw all the WARNINGS (see attachment - yes, 5 WARNINGS) - Caveat Emptor!

27

Do-more CPUs and Do-more Designer Software / Re: MEMCOPY to a Partial Structure

« Last post by franji1 on January 25, 2023, 02:13:39 PM »

Am I correct that to MEMCOPY a block to a string, the first DWord (Len, MaxLen?) needs to be 0x00080008? As far as I can test it populates each time when that's the case, and not when not the case.

Realize that the .Len could technically be anywhere from 0.. .MaxLen based on the specific string (e.g. "" 0 vs "a" 1 vs "ab" 2 vs "abcdefgh" 8).  Or is the Modbus Master actually always padding it with spaces to get to 8 character text length always?  The "safe" way is to just use STRPUTB (not MEMCOPY). that is "smart" regarding the character text only, and intelligently sets the .Len and maintains the .MaxLen (no way for Modbus Master to corrupt .MaxLen).  STRPUTB is also smart that if .Len the Modbus Master sent was 9 or more, STRPUTB would still only copy 8 (actual .MaxLen) and truncate it, not corrupt the memory (this is a SERIOUS problem with MEMCOPY).  MEMCOPY could work, but STRPUB is safer.

28

Do-more CPUs and Do-more Designer Software / Re: MEMCOPY to a Partial Structure

« Last post by Bolt on January 25, 2023, 01:36:42 PM »

Excellent idea. I had gotten as far as making a separate UDT for proof of concept, but the thought had not occurred to me to make that a nested structure inside the primary. The only issue there is that I have a string structure inside it, so I'll bump into the double nested structure limitation, but I can work around that by having Primary.String and Primary.Parameters, and just MEMCOPY twice to get both units filled. Much better than individually populating everything across the board.

Am I correct that to MEMCOPY a block to a string, the first DWord (Len, MaxLen?) needs to be 0x00080008? As far as I can test it populates each time when that's the case, and not when not the case.

29

Do-more CPUs and Do-more Designer Software / Re: MEMCOPY to a Partial Structure

« Last post by franji1 on January 25, 2023, 12:46:58 PM »

You can do individual field by field, OR

Create a new UDT called StatusStruct, then add those individual Status fields from the original UDT to the StatusStruct, THEN create a .Status field in the original struct that is a StatusStruct.  Then from MEMCOPY from MHR to Original.Status member.

The First attachment shows the MEMCOPY referencing a UDT w/a field called .Status that is a nested UDT.  I am copying MHRs into that sub-structure that is 2 DWORDS or 4 WORDs long (hence MHR10-MHR13 is copied on top of the .Status that itself is a UDT.  Note the Source, Destination and Number parameters in the MEMCOPY.

The Second attachment shows the main UDT definition that contains a field called .Status that is a StatusStruct.  The Third attachment shows the UDT definition of that subfield's structure StatusStruct.

30

Do-more CPUs and Do-more Designer Software / MEMCOPY to a Partial Structure

« Last post by Bolt on January 25, 2023, 12:15:15 PM »

Is there a way to copy a block of data into a partial structure? I have an MHR block with parameters, and I would like to copy it into a UDT that also contains status, etc towards the end of the structure, is there a way to copy words 0 -11 into the UDT and leave the last words 12 - 17 unaffected?