MODBUS was designed to be friendly to those who thought in relay logic terms - not computers. Hence Coils (relay coils) as output devices.  :)

  Tinine said  

I understand those who promote CRC but as the saying goes "nobody got fired for buying IBM".

I will have to provide the CRC outgoing to the Renogy device, since that's what it expects, but plan to ignore it incoming, since nothing will be smashed or harmed if there are uncaught errors, since this will simply be for data reporting and logging.

If I start setting parameters (registers) with this method, then I may have to do the CRC checking.

Speed is of no importance here--I thought I'd start off getting the data (State Of Charge, Battery Voltage, Solar Panel Voltage, Panel Current, etc. every 10 seconds or so). This device knows nothing about the load other than through seeing the State of Charge decline.

  Quote  

MODBUS was designed to be friendly to those who thought in relay logic terms

Actually I think that statement refers to the MODICON documentation for MODBUS. It is the worst enemy of MODBUS. MODBUS is a simple, reliable protocol and if you can get over the references to coils, register addresses holding registers etc it can be very easy to understand.

If one of the C gurus could write a CFunction for the CRC the "unacceptable" few mS to calculate the CRC in BASIC would be gone (not for all of course). There are many examples of the MODBUS CRC available on the web.

Bill

@Turbo46

  Quote  

"unacceptable" few mS

I am the absolute worst for this and I realise that I'm being ridiculous.

I sometimes use an online Tone Generator, input 100Hz square wave and listen to it to remind myself of what 10ms is    

The really, really ridiculous thing?
I drive lots of hydraulic valves and the MMBasic PULSE command works well for me BUT I have to establish a minimum pulse of 150ms. Anything less and the valve can't respond.    

I even count clocks on the Propeller and nothing I'm capable of would make that thing break a sweat.

I guess I have programmer's OCD  

Craig

It's not the time it takes to do CRC that bothers me - it's the fact that it seems to be a black art (no matter how many examples I look at). On top of that, the more I look at it the dafter it appears to be for a standard - that's what's so good about standards, you can have any number of them and all incompatible. Checksums I can understand. :)

Then again, I'm not much of a programmer in any language and I'm very easily confused by this stuff. Although I've seen CRC used in MODBUS stuff, it's not something I've ever had to actually use myself. The firmware handled all that.

@Tinine I did say (not for all) you have explained what you do before and I get the gist of it. The following rant is not for you.

But those who are transmitting data over some medium or other should use a CRC if they value the integrity of that data. It's not difficult to do, it's there in Fruit of the Shed and you don't have to understand how it works, just use it. The MODBUS CRC is NOT restricted to MODBUS. It's just the CRC of a string of data. XMODEM CRC is similar and could be used in exactly the same manner. I just don't understand the reluctance.

Bill

  Mixtel90 said  

It's not the time it takes to do CRC that bothers me - it's the fact that it seems to be a black art (no matter how many examples I look at). On top of that, the more I look at it the dafter it appears to be for a standard - that's what's so good about standards, you can have any number of them and all incompatible. Checksums I can understand. :)

That made me  

But we all want to further the MMBasic cause so I like the idea of a fast CRC.

As much native/almost-native stuff for MMBasic the better as opposed to the Arduino world of "oh,don't worry about it there's a library"  

It's about time that Pimoroni and The Pi Hut recognised MMBasic, BTW  

All's fine, Bill, using pre-packaged CRC while everything is working. The problem comes in fault-finding it when you try to talk to something that's using a different initialising value or something like that. Without some understanding of how it works you're in the wet and smelly as even a logic analyser won't tell you what's wrong.

Don't get me wrong - CRC is a great system from what I can understand of it. Far better than a checksum, but it does have its negative points too - one being that manufacturer A's gear won't necessarily work with manufacturer B's gear. If it's your own stuff then fine, no problem.

The variations seem t have been largely commercial driven - to lock people into a product. There's no need for them. CRC was, apparently, designed to be calculated and checked using logic gates, not software.

True to a point Mick, too many 'standards' look at an on-line CRC calculator and it's hard to find the one you need.

A MODBUS device uses the MODBUS CRC or it's not MODBUS. It has been used by a few members on this forum to communicate with MODBUS compatible gear. TassyJim wrote the first one in MMBASIC for one such member.

Using a CRC in your own system is not a problem because you will use the same routine in both ends. That's the main point I'm trying to make.

Bill

  Mixtel90 said  

It's not the time it takes to do CRC that bothers me - it's the fact that it seems to be a black art (no matter how many examples I look at).

It sort of is. It's based on logic gates (as has been posted) with feedback, so the software tends to look ugly.

I've looked at the logic gate circuits and gone OUCH, WTF!? And pretty much the same with the software version of them. Doesn't matter, just use it because it works.

The different CRCs tend to reflect real world issues e.g. that the first byte of a message might quite likely be a specific value (or missing) which a particular CRC would not detect but a different CRC would.  (This can by why one CRC might start with an initial value, say hex FFFF, whereas another might be zero.)

(I expect the hardware guys, given the logic gates circuit, could see why a given circuit could fail in the above situation.  Occasionally I have, studying the software.)

It doesn't take long to calculate a CRC even in MMBasic, though - and if it seems too long you're probably either wrong (sorry) or doing the CRC over a whole message rather than byte by byte as it comes in.  In that latter case, just do it byte by byte!

John

Surely byte by byte CRC is even slower than on the complete message? You can't signal NAK until you've got the entire thing anyway - there isn't time and it's quite possible the TX end isn't listening on a half duplex system. Byte by byte restricts the byte rate, message CRC causes longer pauses between messages but keeps the byte rate high.

  Mixtel90 said  

Surely byte by byte CRC is even slower than on the complete message?

Overall time taken, yes.

You'd use it when the time taken to do the CRC on the whole message is too long.

On many systems you've plenty of time to do the CRC byte by byte without missing data coming in or breaking other real-time constraints.

John
Edited 2022-03-16 19:53 by JohnS

  Mixtel90 said  

keeps the byte rate high.

Well, when you add 2 bytes CRC for every byte you send, you force the byte rate up. You are sending 3x as many bytes...

good point. :)

Been rock-solid for many days now. Bombarding two PicoMites from the Propeller @460KBaud.

I'm using Schottky diodes.

Feeling a bit guilty, relegating this awesome device to I/O expander but it's really cool. They are running watchdogs and are able to shut down the machine should anything go awry.



Craig

Ref: "Gemini" thread.

Seems like this discussion from a few months ago has been forgotten.

That solution looks more complicated than I remember...

RS485 is not so bad... I played with it WAY back... as I managed to find a bag of Texas Instruments 485 chips and toyed with SNAP protocol instead of MODBUS (Which I found confusing back in the 90s).

SNAP Protocol

  Volhout said  

  Mixtel90 said  

keeps the byte rate high.

Well, when you add 2 bytes CRC for every byte you send, you force the byte rate up. You are sending 3x as many bytes...

Er, why add 2 bytes CRC for every (as in: each) byte?

John

  Quote  

Well, when you add 2 bytes CRC for every byte you send

No protocol that I know of does that?

It's one or two CRC bytes per message or block of data

Bill

It's working really well. Been hammering it for a few days now. Not a glitch  

Four RP2040s talking to a Prop-2 @460K Baud:





Craig