Announcement

Collapse
No announcement yet.

CLICK Basic Serial Communication

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts


  • CLICK Basic Serial Communication

    Attempting to communicate with a BK Precision power supply using RS-232. Commands which are sent out by the CLICK C0-00DD2-D are being read by the supply because I can see the display update. The command to read voltage returns a 9 character string, and sometimes the first 1-2 bytes are not received. So its getting 15.00000 instead of 115.00000. This issue started occurring after I added some unrelated code. I changed to a fixed, 6ms scan rate, and the issue was resolved. Now, the application is growing in size again, and it's running over the 6ms. Changing to variable, or fixed scan at 8 to 12ms has not fixed it. The receive command is a fixed length of 9 bytes. Using the $0A termination character causes other issues.

    Looked at the response with a separate PC, and the data is always consistant. Should I be starting the RX command, and then send the request? Anyone have examples?
    Attached code - see Read Voltage subroutine.

    Greg

    Click C0-00DD2-D C-More HMI


  • #2
    If you sending a request and then trying to read the response, you may need to go to an Ethernet click. They have a faster processor and are better suited for this.

    Comment



    • #3
      Got this working by re-wrting to reduce execution time. When buttons are pressed by the user, I set a flag, and then handle them later, using an Enum so it's only executing certain pieces of the code in any given scan. and was able to leave it at a fixed scan rate of 6ms.

      Comment



      • #4
        GHost Rider, I've tried implementing 2-way serial communication with AD's step drives (I forget the specific P/N off the top of my head), and bottom line was that Clicks cannot perform asynchronous serial communication. It's great at only sending, or only receiving, but not both on the same port with one device (if you'd like more details, search for my posts on here, you should see them). As you have done, you need to have the scan time synchronized with sending and receiving to the serial device. If it's running consistently and you are satisfied, then keep moving forward. I had tried tuning the scan time, but I had a feeling that a system that delicate will haunt me over time with repeated fixes and tweaks, so I dropped the 2-way communication idea.

        My suggestion for future projects is to go with a Do-More system; it handles asynchronous serial comm. beautifully. I have not tried Click's Ethernet implementation, so I cannot comment on how well that works.

        Comment



        • #5
          Originally posted by bgirouard View Post
          GHost Rider, I've tried implementing 2-way serial communication with AD's step drives (I forget the specific P/N off the top of my head), and bottom line was that Clicks cannot perform asynchronous serial communication. It's great at only sending, or only receiving, but not both on the same port with one device
          If the communicated-with device is slow in its response - and you NEVER attempt full duplex, this works OK.
          We have some TDK/Lambda Gen600 power supplies (RS-232) controlled by CLICKs.

          Comment

          Working...
          X