zzz

Forum Replies Created

Viewing 15 posts - 106 through 120 (of 165 total)
  • Author
    Posts
  • in reply to: Administrator Channel pane on LInux #9195
    zzz
    Participant

    OK, got it. So that is .net core which I alomost lost track of.

    Does V6 and V5 server communication API has a lot of major change ?

    in reply to: Administrator Channel pane on LInux #9187
    zzz
    Participant

    Could you explain what you mean by abandoning Mono ?
    Do you mean abandon .NET for Administrator, or are there are other alternative for Mono on Linux?

    in reply to: Signal Relative ID to Fixed ID ? #9185
    zzz
    Participant

    I was wondering why not use starting adress as the signal id in the first place (they are numeric, sequential, not continuous but unique, ).

    While the V6 solution sounds good, I just wonder if the tags can be sorted easily by register start address, either automatially/by default/manually ?

    Having a labeled register block layout overview is a realy nice thing. I think the template editor in V5 seems close to that, even if not perfect.

    zzz
    Participant

    Kind of emergency here, due to the system freeze issue. Maybe I can create a minimum setup to replicate the issue, after my system immegration work is done…

    zzz
    Participant

    Nope. Windows was using … maybe the last release not current relese or maybe even older. Linux is using lastest release, as this thread was started, on official site for Linux.
    I was also wondering if that what Linux fault. But

    Because the immigration was caused by a windows corp. security software updated that causes ramdom windows freeze (unacceptable for control pc), I pulled the latest dev branch code and compile the KpModbus module, copied it to Linux, it didn’t work. I copied it to Windows, RS on windows stopped working either.
    The frame hex code in log on both machine are identical – wrong data, different from previous Windows frame.

    Working Frame Sent on Windws

    
    03 7b 00 00 00 0B 0E 10 02 0E 00 02 04 9F 6F 46 9A
                                     || ||
                                  2WORD ||
                                        4bytes
    

    Wrong Frame sent on Linux

    
    00 79 00 00 00 0F 0E 10 02 0E 00 02 08 9F 6F 46 9A 00 00 00 00
                                     || ||
                                  2WORD ||
                                        8bytes?
    

    If I set element qty to 1, the trailling 0s are gone, the byte count become valid, but the register count will be 1, which should be 2 (1 float =2 WORD = 4Byte).

    As was explain in my last post, I am confused what ElemCount was supposed to mean here, ElementReigsterCount/WORDCount or ElementCount, thus I am not sure what’s the correct fix, so I just replace ModbusUtils.GetDataLength(ElemType) with 2. then it works, on both linux and windows, the generated request frame become
    {{{
    03 7b 00 00 00 0B 0E 10 02 0E 00 02 04 9F 6F 46 9A
    }}}

    If ElemCount was supposed to mean ElementCount, there is another issue, in the DeviceTemplate Editor, the Element Count field on Command right pane will change as the user select different element data type, e.g. if 4byte float was selected, Element Count will be automatically set to 2, which I supposed means 2 words/register per element, or how does the editor know I send 2 element instead of 1 or 3 Element ?

    • This reply was modified 4 years, 3 months ago by zzz.
    zzz
    Participant

    {{{

    ReqPDU = new byte[6 + dataLength];
    ReqPDU[0] = FuncCode;
    ReqPDU[1] = (byte)(Address / 256);
    ReqPDU[2] = (byte)(Address % 256);
    ReqPDU[3] = (byte)(ElemCnt / 256);
    ReqPDU[4] = (byte)(ElemCnt % 256);
    ReqPDU[5] = (byte)dataLength;
    }}}

    I always thought by ElemCnt you mean Element Word Count.
    Since In the Device Template Editor, changing the data type, the “ElementCount” field changes, 2 for float, 4 for double, which is number of words.
    And in above code ElemCnt is set to reg (WORD) qty in PDU ,
    then GetDataLength() shoud reture a constant 2 for non bool types.

    But if you really mean Elemnt Count, then ReqPDU[3:4] should not be set to ElemCnt.

    ElementCount, DataLength etc are very confusing on first glance, initially I guess they are in WORD unit, but it takes more crunching to understand. Maybe it can be reworded.

    zzz
    Participant

    e.g.

    Send (17): 0B 1A 00 00 00 0B 0E 10 02 0E 00 01 04 46 B8 2E AB
    Receive (7/7): 0B 1A 00 00 00 03 0E
    Receive (2/2): 90 03
    Device error: [03] ILLEGAL DATA VALUE!

    zzz
    Participant

    I am on developer branch, Github is taking ages to open, please see source, there is byte count is doubled, not sure why.

    I am not sure how such problem is not detected in months. I guess, this should be recent change. The Linux instance is setup just yesterday. Windows was long time ago.

    ModbusCmd.cs L149
    {{{
    // формирование PDU для команды WriteMultipleCoils или WriteMultipleRegisters
    int dataLength = TableType == TableType.Coils ?
    ((ElemCnt % 8 == 0) ? ElemCnt / 8 : ElemCnt / 8 + 1) :
    ElemCnt * ModbusUtils.GetDataLength(ElemType);
    }}}

    ModbusUtils.cs
    {{{

    /// <summary>
    /// Gets the length required to store element data depending on the element type.
    /// </summary>
    public static int GetDataLength(ElemType elemType)
    {
    return elemType == ElemType.Bool ? 1 : GetQuantity(elemType) * 2;
    }

    public static int GetQuantity(ElemType elemType)
    {
    switch (elemType)
    {
    case ElemType.ULong:
    case ElemType.Long:
    case ElemType.Double:
    return 4;
    case ElemType.UInt:
    case ElemType.Int:
    case ElemType.Float:
    return 2;
    default: // Undefined, Bool
    return 1;
    }
    }

    }}}

    zzz
    Participant

    Linux Mono, same data, injected with generator
    {{{
    00 79 00 00 00 0F 0E 10 02 0E 00 02 08 9F 6F 46 9A 00 00 00 00
    }}}

    zzz
    Participant

    Hi Mik,

    I don’t understand what you mean. My question is
    for a module that only want to process current snapshot, and ignore any per minute or per hourly averaged data,
    when it receives this event, how does it know if the data returned is for calcDR, calcMinDR, calcHrDR?

    in reply to: DbImport module missing channel data #9053
    zzz
    Participant

    Hi Mik,

    I am just looking for cludes or direction for further debugging the issue. The investigation, coding, debuging are all done on my own, and the discussion is on public domain. I don’t see why it has to be charged.

    Plus the modautocontrol I already paid did not work as expected. It has problem (now I realized of the same pattern), certain channels in triggered doesn’t work, or not triggered sometimes, while other channels works perfectly. We overcame the problem by removing channels from modautocontrol and resolving the logics only in formular, leaving modautocontrol blindingly forwarding resulting data to output channel.

    I think both module are experincing problem of the same nature. Even if I write my own module, or using your new moddbexport module, it’s dubiou this problem can be solved.

    in reply to: DbImport module missing channel data #9044
    zzz
    Participant

    I have updated the code to subcribe to both OnCurDataProcessed() and OnCurDataCalculated(), I didn’t check all the channels, but for channel 1403, its very weird: there is no change. The WebStation data looks perfect as usual, and the db data remain scarce.

    I also tried replacing OnCurDataProcessed() with OnCurDataCalculated().
    Only difference is empty cnldata count in log now is constantly 0.
    The issue remains, 1403 channel has perfect graph in webstation, but export data remains little, only has commited data when it appraches 0, and goes back up after sometime.

    I suspected I made any mistake in the commit process esp. the ON CONFLICT DO NOTHING in sql looks dubous. Thus I hardcoded checks for channel 1403 in EnqueueCurData() function, there is no 1403 shown in log at all.

    1403 is a calculation enabled channel, like 1407, but 1407’s data in db looks very OK. I am running out of ideas to try or invesigate. 🙁

    • This reply was modified 4 years, 4 months ago by zzz.
    in reply to: DbImport module missing channel data #9043
    zzz
    Participant

    After a bit reading, I get the impression that

    OnCurDataProcessed() is event based, and provides both plain and calculated data. (Judging from the current issue, it seems that) based on the loop and event timing, the calculated data may be incomplete.

    OnCurDataCalculated() is loop based (and paced).
    it provide calculated data only (but one has to know the way to tell if the calculated data is averaged, per min, per hour, or original data, not clear how to do it, so I created another question).

    It seems that if I want to get this fixed now in the current module way,
    I need to
    – get all calcualted channel number
    – subscribe to both OnCurDataProcessed() and OnCurDataCalculated event,
    – skip calcuated data in OnCurDataProcessed()
    – figure out how to tell hour/minute data from current data ?

    Do you think the above changes will solve the missing data problem for formula-enabled channels for this module?

    Regards,

    in reply to: DbImport module missing channel data #9041
    zzz
    Participant

    PS: If I write external client using Scada.Client to connect to server externally, rertive data via TCP and export to database, do you think this will solve the formula-enabled cnldata with empty data problem ?

    Or is this solved in the new export module already ?

    in reply to: DbImport module missing channel data #9040
    zzz
    Participant

    Hi Mik,

    A small suggestion, could you add timestamp to the Srez object upon server reception? I think for some reason, the module self-added timestamp and webstation data timestamp does not align very well…

    Uh, I guess I should confirm this before assumption, does OnCurDataProcessed() hook guarantees formula processing completion ?

    Regards

Viewing 15 posts - 106 through 120 (of 165 total)