Jump to content

Unitronics PCOM Protocol

Unitronics PCOM Protocol
This describes the telegrams used to communicate data between PC and OPLC.

29 topics in this forum

    • 7 replies
    • 7 replies
  1. Binary Write

    • 6 replies
    • 2 replies
    • 0 replies
    • 0 replies
    • 2 replies
    • 5 replies
    • 12 replies
    • 21 replies
  2. help

    • 2 replies
    • 1 reply
    • 1 reply
    • 2 replies
    • 16 replies
  3. Pcom

    • 1 reply
    • 1 reply
    • 0 replies
  4. PCOM over TCP

    • 2 replies
    • 2 replies
  5. PCOM via Radio Modem

    • 0 replies
  6. PCOM with Hyperterminal

    • 2 replies
  7. Programming HMI

    • 1 reply
  8. Reading Data Tables

    • 10 replies
    • 4 replies
  • Member Statistics

    Total Members
    Most Online
    Newest Member
  • Topics

  • Who's Online (See full list)

    There are no registered users currently online

  • Posts

    • Three questions related to tables in DataXport.  If I have the V570 in a testing device which has programs for each product I'm testing, and each of those programs saves a separate results table (Samples_P01, Samples_P02, Samples_P03, etc.): 1)  If I download a table from the PLC using DataXport, is there a way to flag it as having been received?  I don't want to download the same data again until all the results in the table have been updated with new results. 2)  How can I switch to another table (which is another product's results) without stopping, editing the site, selecting the table, unselecting the previous table, and running again?  The other option I found is to create multiple sites for the same PLC, each with a different table selected.  This still requires you to stop the call log, edit the current site to uncheck enable, edit the other site to check enable, then running again.  Just as much work. 3)  Is there a way to pull the table without using schedules?  I don't want the data to continuously pull every minute or hour, but rather only when the operator performed new tests.  Otherwise, I am getting the same data over and over in new CSV files.  I'd rather force a call when they need it and bypass schedules.
    • I've been doing this for many many years and can't remember the last time I needed floating point numbers in my program except for some crazy flowmeters that insisted on outputting their data via MODBUS as floating point. Insane, if you ask me. I guess if you have a situation where the number of significant figures in the decimal varies and is unknown at the time of programming then floating point is necessary. Other than that it's poor programming practice in my humble opinion.
    • In UniDDE, if you right click on your open project or use the menu buttons, you can copy the Read Command, Stop PLC Macro, Run PLC Macro, and Run/Stop Toggle macro.  If I have the read command in an Excel worksheet, it tries to start UniDDE.exe but fails.  Instead, I had to clear the field until the workbook is open then add the read command =UniDDE|Items!'lblDDE(1)' to the cell afterwards.  My second issue (the first being that I can't seem to get the UniDDE read command to automatically load the software) is that the PLC is not in Run mode.  Therefore, I try to use the code that UniDDE provides with those copy buttons.  If I use the "Run/Stop" toggle it will properly stop the PLC connection if it's already running.  If I execute that code to make it run, it will run but Excel freezes until I click escape.  I also tried the "Run PLC" macro, but it does absolutely nothing.   My VBA to start the UniDDE software is below.  Cell F1 = "C:\Program Files (x86)\Unitronics\Unitronics DDE Server\UniDDE.exe" Cell F2 = "UniDDE.exe" Cell F3 = "U:\Display Result and Write CSV.ude" Sub Load_UniDDE() Application.StatusBar = "loading PLC application" Dim strApp, strAppShort, strFile As String Dim WB As Workbook Set WB = ThisWorkbook strApp = WB.Worksheets(1).Range("F1").Value strAppShort = WB.Worksheets(1).Range("F2").Value strFile = WB.Worksheets(1).Range("F3").Value If strApp = "" Or strAppShort = "" Then Application.WindowState = xlMaximized WB.Worksheets(1).Range("F1").Select MsgBox "Please correct the software path and process in the Excel worksheet." Else If Dir(strFile) <> "" Then Dim objList As Object Set objList = GetObject("winmgmts:").ExecQuery("select * from win32_process where name='" & strAppShort & "'") ' determine if the DDE app is already running If objList.Count = 0 Then Shell strApp & " " & strFile, vbMinimizedFocus ' open the DDE app and project file End If Else Application.WindowState = xlMaximized WB.Worksheets(1).Range("F3").Select MsgBox "Please correct the project path in the Excel worksheet." End If End If Application.StatusBar = False End Sub UniDDE provides the following macros which are not working properly RUN PLC: Dim lchannelNumber As Long '/ Run PLC lchannelNumber = Application.DDEInitiate("UniDDE", "Items") Application.DDEExecute lchannelNumber, "Last Test Result_RUN" Application.DDETerminate lchannelNumber RUN/STOP Toggle: Dim lchannelNumber As Long '/ Run/stop UniDDE lchannelNumber = Application.DDEInitiate("UniDDE", "Items") Application.DDEExecute lchannelNumber, "UniDDE_RUN/STOP" Application.DDETerminate lchannelNumber  
    • Fantastic.  That is very helpful.  I can appreciate 'almost never'. That being said, my program has evolved over time, 2 different system integrators, and now me.  There are real numbers used in several places...generally related to drives and encoder outputs, speed, etc.  Is this the 'right' time to use real numbers, or just another way to handle those things?   I'm actually just converting from displacement/position to volume.  Little bit easier, but I will keep this in the back of my mind.  
    • Almost never. Multiply by 100 or 1000 (or whatever precision you need) in your linearization function block and then keep track of the location of the decimal point through any subsequent calculations. The HMI display function for integers has a handy virtual decimal point that you can use for display. I spend most of my time with VisiLogic rather than UniLogic, but my recollection is that the 16-bit integer registers are signed (VisiLogic has both signed and unsigned 32-bit registers, and only signed 16-bit registers - I think UniLogic is the same). Just use negative numbers as you normally would. Just be careful about register overflow and divide by zero. It seems I'm always dealing with converting flow rates to volume (most of the time) and volume measurements to flow rate (less often). Either many system designers don't understand that they need to use the proper sensor for the job at hand or they just go with whatever is cheaper at the moment (sometimes you need both flow and volume so conversion is necessary regardless). Converting between those two domains is very cumbersome and elegant solutions are rare. For converting flow to volume, you need to integrate. I just time slice the flow (usually in 100ms increments) and sum (there is some additional math involved to get the units correct). For the reverse, you just have to measure the volume as often as you can, calculate the time interval and filter as heavily as needed to get something approximately matching reality. If there's a better way, I sure would like to hear it.
  • Blog Entries

  • Create New...