Shop OBEX P1 Docs P2 Docs Learn Events
Modbus process kills stdTV! — Parallax Forums

Modbus process kills stdTV!

Charles EdmondsonCharles Edmondson Posts: 46
edited 2013-10-12 15:27 in Propeller 1
Hi All,
Well, another thrilling descent into the abyss of debugging! A really strange one...

I am adding MODBUS to an existing product that was using CAN before. I am using Pacman's MODBUS RTU code, which I have expanded to handle a custom group of registers. The product also uses the standard stdTV, stdGraphics and stdTerminalMgr spins to generate a TV display of local status. When I add in my MODBUS code, it somehow breaks the TV code! I just get a blank screen output.

Now, try as I might, I can not find any way my code would interact with the TV code. They are on different physical pins (the same ones used by the old CAN software) and I don't see any code overlap between them. No common variable names, except in their respective assembler code. Any ideas out there what could be causing this? Could I be running out of cogs? How can you tell from the compiler????

Any ideas would be appreciated.

BTW, my MODBUS code works fine, even with the screen down...

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-10-03 19:25
    You didn't run out of cogs, did you?

    -Phil
  • Charles EdmondsonCharles Edmondson Posts: 46
    edited 2013-10-03 22:04
    How can I tell?

    I tried downloading one of the four serial port objects to replace my two separate serial port routines, which should have restored at least one cog, but still have the same errors - when I add in the start routine for the modbus, I get no TV. comment out the start routine, and I have TV.

    So, how can a Modbus routine interfere with the TV routine?????
  • AribaAriba Posts: 2,690
    edited 2013-10-03 22:37
    Does it perhaps set one of the TV pins to high?
  • Charles EdmondsonCharles Edmondson Posts: 46
    edited 2013-10-04 22:28
    No, uses separate pins and processes, and verified with the Oscope...
  • kuronekokuroneko Posts: 3,623
    edited 2013-10-04 23:22
    @Charles: Can you please post your code so we can see what's going on? Guessing isn't going to get us anywhere.
  • Charles EdmondsonCharles Edmondson Posts: 46
    edited 2013-10-07 10:06
    Wish I could post my code, but this is a large project, and I am just doing an 'update' to it. Most of the code is proprietary. However, the Modbus and TV code are OBEX, so I was wondering if anyone knew of any known problems.

    It is interesting that the TV routines, while OBEX, are old, dated 2004! Too bad there isn't some history somewhere that I could see what updates have been made since then, and why!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-10-07 10:40
    The MODBUS RTU object is hard-coded to use P14 as a serial output -- one of the same pins frequently used for TV output. Did you remember to change this pin assignment?

    -Phil
  • Charles EdmondsonCharles Edmondson Posts: 46
    edited 2013-10-08 17:05
    Yes, TXpin is now Pin0, and RXpin is now Pin9. It does work if on those pins, but when the Modbus process is active, stdTV is dead.

    Thanks for the suggestion though!
  • Charles EdmondsonCharles Edmondson Posts: 46
    edited 2013-10-08 18:57
    If anyone would like to take a look at this, I am uploading a simplified version of the problem. The vital line in the demo file is

    mod.Start

    If you comment it out, the TV runs. If you don't, it doesn't

    !TV_MODBUS_PROBLEM.zip
    zip
    zip
    TV_MODBUS_PROBLEM.zip
    33K
  • kuronekokuroneko Posts: 3,623
    edited 2013-10-08 19:04
    Charles Edmondson wrote: »
    If anyone would like to take a look at this, I am uploading a simplified version of the problem.
    Said start method never returns (endless loop). IOW it never starts the TV driver in the first place. The start method should start a new cog with whatever code you need to run concurrently.
  • Charles EdmondsonCharles Edmondson Posts: 46
    edited 2013-10-09 07:55
    Ok, that sounds promising. So, how does one start a new cog...
  • Charles EdmondsonCharles Edmondson Posts: 46
    edited 2013-10-09 09:26
    THANK YOU!!

    I split the Start routine into two parts, the initializer and took the bottom half with the receive process and call it MODBUS and started it in a new cog. It works! Now to go back to my original code and fix it there...
  • Charles EdmondsonCharles Edmondson Posts: 46
    edited 2013-10-12 15:27
    Well, I have made a lot of progress. I can now do all my needed routines to an RS232 serial port, but I have a requirement for RS485 as well. I have added in the TxEn pin, toggling it while I transmit. Had fun with that, as I was setting it up in the initializer portion of the code, but needed to also add the DIRA for the pin inside the MODBUS cog code as well.

    My problem now is that there seems to be corruption of the packet. I can see the packet getting to the processor receive pin, but I keep sending exception errors back. Since I get enough of a packet to be able to process it, this is driving me crazy. Earlier today, with the same code, I was actually replying correctly, but my receive channel kept giving me an error of 'packet too long' which didn't help a bit!

    Anyone worked with RS485 lines that knows what problems I could be running into?

    THANKS FOR ANY HELP YOU CAN GIVE ME!!
Sign In or Register to comment.