Shop OBEX P1 Docs P2 Docs Learn Events
Modbus rtu on propeller — Parallax Forums

Modbus rtu on propeller

AHMET AKSUAHMET AKSU Posts: 62
edited 2015-01-03 15:45 in Propeller 1
Hi.i want to connect 1 pc (master) and 10 propeller (slaves) with rs 485.i want to use modbus rtu for the protocol.
Are there anybody who try this before.any code sample?

Comments

  • pacmanpacman Posts: 327
    edited 2013-03-27 13:51
    I'm currently working on an implementaion.

    Others have done the same.

    My code is attached.

    It has LOTS of fuzzy edges right now and is NOT complete, but it might help. Constructive critism welcomed

    Modbus_PAC.spin
    spin
    spin
    Modbus_PAC.spin
    199K
  • JonnyMacJonnyMac Posts: 9,105
    edited 2013-03-27 13:56
    I've done it too, and it's been deployed in a big commercial app. That said, it presently uses two cogs and I'm working on bringing it down to one.
  • AHMET AKSUAHMET AKSU Posts: 62
    edited 2013-03-27 20:39
    thank you pacman and JonyMac.
    I want to test the code pacman.then I want to say my ideas
  • survarsurvar Posts: 2
    edited 2015-01-01 18:47
    Hi Guys,

    Need some help with Modbus RTU implementation on the Propeller Activity Board using the Modbus_PAC code. The setup is as follows:

    PC <--> (RS232-RS485 Converter) <--> Propeller with RXpin = 9, TXpin = 8.
    To test implementation, I am using the QModBus simulator to issue commands.

    The code receives commands from the PC (QModBus) properly. For example read holding register (x03) is received and the ReadRegisters and SendOut functions are executed. I tried PST to see the returned value from SendOut. It looks the correct value. But QModBus shows error "Slave threw exception > unknown error".

    Any thoughts what could be the reason.

    Thanks....
  • Duane DegnDuane Degn Posts: 10,588
    edited 2015-01-01 19:57
    survar wrote: »
    I tried PST to see the returned value from SendOut. It looks the correct value. But QModBus shows error "Slave threw exception > unknown error".

    I'm not really sure how your system is set up but Modbus RTU doesn't use ASCII characters. If the data is showing up in PST, then I'd think it's not formated as Modbus RTU.
  • survarsurvar Posts: 2
    edited 2015-01-01 20:38
    Duane Degn wrote: »
    I'm not really sure how your system is set up but Modbus RTU doesn't use ASCII characters. If the data is showing up in PST, then I'd think it's not formated as Modbus RTU.


    Thanks Duane....This is the bit of code in the function SendOut that does transmit using FullDuplexSerial object.

    PRI SendOut (buf)| j

    ' Transmits the data back to the host system.

    ' params: buf - the data stream we want to transmit
    ' return: none

    'NOTE the first element of the array contains the length of the array thus we need to send out buf[0] bytes of data

    PST.newline
    PST.str(string("Send Buf"))
    PrintBuffer(buf) ' just for debugging - delete later if required

    'ser.RxTime(500)
    'ser.RxFlush

    'repeat j from 1 to byte[buf][0] -1
    ser.Tx(byte[buf][j])


    PrintBuffer prints to PST, it is as follows:

    PRI PrintBuffer(print) | k

    ' Just dumped the buffer to the debug terminal

    ' this method can be deleted once all testing has been done. Any call to Printbuffer can then ALSO be deleted.

    PST.newline
    PST.str(string ("PrintBuffer "))

    repeat k from 0 to (byte[print][0] -1)
    PST.newline
    PST.hex(k,2)
    PST.str(string (" : "))
    PST.hex(byte[print][k],2)

    The code is fetching correct data from the holding registers and the CRC calculation is correct, but the transmit back to master is failing for some reason. I am not sure if its the formatting of the transmit frame or something else.

    The Modbus RTU object from OBEX is attached. Any help is appreciated.

    Thanks
    zip
    zip
    Modbus_PAC - Archive [Date 2013.04.27 Time 19.03].zip
    23K
  • Duane DegnDuane Degn Posts: 10,588
    edited 2015-01-01 21:33
    As you can see, the forum software doesn't preserve indentation. To post code you need to use code tags [noparse] 
    paste your code between the tags.
    [/noparse].

    I worked on a project which used Modbus RTU and I was successful in getting the Propeller to communicate with the Modbus master (I wrote my own Modbus code, I didn't use the object in the OBEX) but I'm far from an expert on the subject.

    One thing I do know is there are lots of variations in the way data is formated. IIRC the data is generally sent most significant bit first but the order in which the bytes are sent isn't always consistent among the various Modbus devices.

    If you post your code with code tags hopefully someone more familiar with Modbus will help.

    It does look like you're treating the data correctly to display to the PST.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2015-01-02 08:04
    I remembered something else as I experienced traumatic flashbacks to programming the Modbus interface.
    Many Modbus devices expect the data to come in with even parity (which none of the commonly used serial objects use). Many of the serial objects send an extra stop bit (at the beginning of the byte) which can also cause a problem with some devices.
    I'll try to find the post about how to add even parity and I'll also try to find Tracy Allen's comments about the extra stop bit.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2015-01-02 08:16
    This is the thread where Tracy Allen kindly teaches me about start bits, stop bits and parity.
    http://forums.parallax.com/showthread.php/155390-Adding-Even-Parity-to-One-Port-in-Tracy-Allen-s-4-Port-Serial-Object
    IMO, there's a lot of good information in the thread.
  • pjvpjv Posts: 1,903
    edited 2015-01-02 10:30
    Hi,

    I seem to recall that in certain cases Modbus *requires* 1.5 stop bits. Don't remember just now what that was for precisely..... some kind of over-riding function I think.

    Cheers,

    Peter (pjv)
  • JonnyMacJonnyMac Posts: 9,105
    edited 2015-01-02 11:09
    You may be thinking of the idle state of the serial line. If an idle period of 1.5 bytes is detected, the message is complete.

    -- http://www.rtaautomation.com/technologies/modbus-rtu/
  • pjvpjv Posts: 1,903
    edited 2015-01-02 15:58
    OK Jon, you are probably right...... it was a recollection from quite a while ago.

    Cheers,

    Peter (pjv)
  • pacmanpacman Posts: 327
    edited 2015-01-03 15:45
    Not sure why it wouldn't be working. couple of things to try

    Slow the the comms (serial sometimes benefits from running slower)
    Try a different convertor (sometimes different brands do 'odd' things' - slowing down comms here can often help)
    Check your 'endian' setting in Qmodbus (though I would also expect the command from the PC to be in error if this was the issue)
    Check the bounds of the command - Modbus has different method of defining where a register array starts - Try reading/wring one register in the middle of the array (that way the whole +1 -1 offset is removed)
    Check your not using Enron Modbus (as it does stuff slightly differently to 'normal' modbus - though I would also expect the command from the PC to be in error if this was the issue)

    Capture the send command (from the PC) and the receive command from the Prop and post them here, then I can see if something more sinister is going on (in my prop code perhaps).
Sign In or Register to comment.