Results 1 to 7 of 7

Thread: MuIn LCD and RS485

  1. #1

    MuIn LCD and RS485

    Hello,

    Since this morning I'm very happy to own a MuIn LCD module.
    My goal is to use it in a RS485 network.
    I've got two questions about this :
    - I see that you are using the "AB" notation which puzzles me a bit. Could you please tell me what A and B stand for in terms of TRX+ and TRX- ?
    Wikipedia has an answer about it but also says not every manufacturer obey the standard, and I would not try to connect it randomly.
    - In your catalog I see that few devices can handle RS485 right "out of the box". I mean, you developed a clever protocol inspired by protocols like Modbus. I already prepared some code to use it, and even made a MuIn LCD simulator to train myself to this protocol. The MuIn DsPic device is a demo board, so I don't think there is a firmware directly handling this protocol like for the MuIn LCD, right ?
    But for the DsNav, which interests me a lot, is there a chance that its firmware handles this protocol already ?
    If that's not the case, are you planning to use this protocol in other devices ? (I find this protocol clever, and the idea of using the last two digits of the device too).

    Thanks in advance,

  2. #2
    Quote Originally Posted by JSavidan View Post
    - I see that you are using the "AB" notation which puzzles me a bit. Could you please tell me what A and B stand for in terms of TRX+ and TRX- ?
    The notation AB is related to the SN75176 datasheet and it is common to all producers of 485 transceiver, A corresponds to TRX+ and B to TRX-.

    - In your catalog I see that few devices can handle RS485 right "out of the box". I mean, you developed a clever protocol inspired by protocols like Modbus.
    The 485 bus can be used as a UART communication direct replacement without any communication protocol, or via a simple multi drop protocol can be activated from the setup section of the GUI.

    The MuIn DsPic device is a demo board, so I don't think there is a firmware directly handling this protocol like for the MuIn LCD, right ?
    Yes, correct.

    But for the DsNav, which interests me a lot, is there a chance that its firmware handles this protocol already ?
    Currently dsNAV not implement any specific protocol for the RS485, but it certainly will be added in the future.

  3. #3
    If that's not the case, are you planning to use this protocol in other devices ? (I find this protocol clever, and the idea of using the last two digits of the device too).
    Sure. We think this protocol is very useful, it's simple, it's cheap and it works almost in every field (robots, industry, harsh environments, etc).

    Do not forget, when using RS485, to take care of pullups and terminations...

  4. #4
    It works great, even on a very low-tech Atari ST
    Thanks !

  5. #5
    Hi everybody.

    The dsNav already has an RS485 hardware. The protocol used in the firmware is a very simple one but it already has some kind of security and multi-device capability.
    It allows an address field in order to be used with a bus but, right now, it's fixed to 0 meaning "broadcast" i.e. addressed to everyone.

    Usually dsNav is used as a slave. On both comm port it never gets the action for first, always waits for command from, in my case, sensors board or PC for a wireless control and telemetry.

    If you already have an idea on how to use RS485 in a multi-device environment, we can study together your needs.

  6. #6
    Thanks for the reply.
    Actually, I'm just having fun using modern technology on an old computer, nothing really serious.
    But, i'm also fan of robots, and would like, as a long term study, to implement a simple robot using an old computer.
    So, RS485 is the perfect choice for me, a RS232/RS485 adapter, and there we go, my Atari is opened to the World and to robotic modules
    Addressing is thus important for me to make sure all modules (computer, lcd, nav, or whatsoever) can be interconnected without one "misunderstanding" a command sent to its neighbour.
    Right now I'm very happy with my module and can control it perfectly, just a few remaks/assumptions :
    - The digital input 4 is always '1' with its pin not connected, I've seen on the "unofficial" GUI that this output is enclosed in brackets "[4]", so I understood that it was perhaps inverted, Am I right ?
    - I "talk" to the lcd module using the RS485 protocol, but it replies without using it, request "@,1,xE,2,xFE,xF1,0,0,#" gets "10" back.
    - with RS485 when requesting Analog Inputs states, I receive 16 bytes, showing all the same value (for example, connecting the input 5 to Vcc i receive FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF), whereas in usb mode I receive the 10 bytes mentioned in the user guide, bug in RS485 mode ?

  7. #7
    - The digital input 4 is always '1' with its pin not connected, I've seen on the "unofficial" GUI that this output is enclosed in brackets "[4]", so I understood that it was perhaps inverted, Am I right ?
    No, 4 is enclosed in brackets to remember that I/O n4 is shared with buzzer and so, if you use the buzzer, isn't available.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •