icanet

MrPLC Member
  • Content count

    11
  • Joined

  • Last visited

Community Reputation

2 Neutral

About icanet

  • Rank
    Sparky

Profile Information

  • Country Spain

Recent Profile Visitors

105 profile views
  1. FB in a Structure

    Yes man, you're right, good contribution!
  2. FB in a Structure

    For example, I create Struct with the members (In, Outs, ans Auxiliar variables) of TON, TOF, TP, R_TRIG, F_TRIG, ans later i make a FUNCTIONS with behaviour of each one, inserting an IO variable (withous IN_OUTs) (for not consume memory). In this way I can introduce this Struct in a parent STRUCT and later in the programmong window I call the funtction with this STRUCT.Struct. a FUNCTION(STRUCT.Struct).  Doing this I lost the input assistant, but is the unique solution at this moment that i have applied.  Using this system, if you want, you can apply for other personal theoreticals FB (Func only with Struct, i name it FDB (Function with DB)). Later, if you want to do METHODS of this FDB, you can create a Func with IN_OUT associating the parent DB (by the FDB), and put a Namespace with the name of the FDB in properties of this METH \nsFDB_xxx\METH_xxx I'm applying this since few days ago, is the unique solution to not harm the memory of the PLC. Postdata: Really important point, array with constant Limit, i think that from developers this is really easy to apply on the enviorenment, and this allows have a better control in the programming code. Is a powerful tool, i hope this in the next updates, please.  
  3. FB in a Structure

    Really George? (What else?) I know it...... OK, for various reasons we are being forced to use the Sysmac Studio environment. I'm solving the previous disadvantages that I mentioned doing some programming tricks. But is better that the environment offers better solutions, really? Nothing more to add.
  4. FB in a Structure

    Please, abstain from being ironic. I know that the Sysmac Studio environment is still young and the developers continue to work on their development; I only bring comments from certain limitations that currently presents and that can be used to try to improve the environment. Your first comment has been an ironic attack where you do not bring anything interesting, we should try be professionals, thank you. Let's leave the misunderstanding at this point. And sincerely, thanks for reading my point of view, I know that after reading it, you will have realized that everything is true.
  5. FB in a Structure

    @skyfox, sorry i'm trying to show some points where the sysmac studio environment could be improved. If you have been lucky (and capable) of being able to test environments such as TIA Portal or environments based on Codesys where you have been able to express your creativity when programming, you will know what I am talking about. For example, the motion environment in sysmac studio is so good, very friendly and powerful. The tools that sysmac studio offers now at this time, harm the performance of the PLCs, due to the fact that it is necessary to do an OVERtreatment of the data, in addition.  If you are not able to see this, you should change your job. I am being a constructive critic, I am not discrediting the environment. Thanks for the comment.
  6. NX1P2 Date to US format?

    You can use the Function DtToDateStruct(In:=, DateStruct=>); // ========================================================= VAR s_dtCurrentTime : DATE_AND_TIME; s_scCurrentTime : _sDT; END_VAR; // ---------------------------------------------------------------------------------------------------- s_dtCurrentTime := GetTime(); DtToDateStruct(In:= s_dtCurrentTime, DateStruct=> s_scCurrentTime); // Access for each member of the DATE_AND_TIME, and the treatment of these members is best done separately (*s_scCurrentTime.Year; [...].Month; [...].Day; [...].Hour; [...].Min; [...].Sec; [...].Nsec*) // ========================================================= I hope I've helped you.
  7. Hello @Jiial, I solved this using this function:  ULINT_type:= "Get1usCnt()"; // ========================================================================================= Precautions for Correct Use Free-running counters start counting as soon as the power supply is turned ON. When the count exceeds the valid range of ULINT data (18,446,744,073,709,551,615), it returns to 0 and counting continues. This instruction only gets the current value of the free-running counter. It does not reset the counter to 0. The start value of Out is not defined. It does not necessarily start from 0. // ========================================================================================= If you want to obtain the Delta System Time (The previous system time of all cycle), you need to do your Function. I do this function: // ========================================================================================= FUNCTION F_GetDeltaSystemTime_ms : LREAL // Delta time extract in 'us', but the output is in 'ms' in LREAL format. Needs an InOut non-volatile variable.   VAR IN_OUT       io_lrPrevSysTime : LREAL; // Auxiliar InOut variable in miliseconds (ms), the time calc is made in microseconds (us)       io_uliPrevSysTime : ULINT; // In microseconds (us), auxiliar InOut variable to store the previous cycle   END_VAR; VAR      t_lrActualSystemTime : LREAL;      t_uliActualSystemTime : ULINT; END_VAR; VAR_CONSTANT      c_LREAL_LONGEST : LREAL := 1.79769313486231e+308; // This Max LREAL value : 1.7976931348623158E+308 not allowed      c_ULINT_LONGEST : ULINT := 18446744073709551615; // Max Value for an ULINT variable END_VAR // ----------------------------------------------------------------- t_lrActualSystemTime := ULINT_TO_LREAL(Get1usCnt()) / 1E3; // 'us' to 'ms'; IF t_lrActualSystemTime - io_lrPrevSysTime  >= 0.0 THEN     F_GetDeltaSystemTime_ms := t_lrActualSystemTime - io_lrPrevSysTime;      ELSE     F_GetDeltaSystemTime_ms := (t_lrActualSystemTime + 1.0) + (c_LREAL_LONGEST - ABS(io_lrPrevSysTime)); END_IF; io_lrPrevSysTime := t_lrActualSystemTime; t_uliActualSysTime_us := Get1usCnt(); IF t_uliActualSysTime_us - io_uliPrevSysTime  >= 0 THEN     F_GetDeltaSystemTime_ms := ULINT_TO_REAL(t_uliActualSysTime_us - io_uliPrevSysTime); ELSE     F_GetDeltaSystemTime_ms := ULINT_TO_REAL((t_uliActualSysTime_us + 1) + (c_ULINT_LONGEST - io_uliPrevSysTime)); END_IF; F_GetDeltaSystemTime_ms := F_GetDeltaSystemTime_ms / 1E3; // 'us' to 'ms'; io_uliPrevSysTime := t_uliActualSysTime_us; // ========================================================================================= I hope I've helped you.  
  8. I wish Sysmac Studio would get things right once and for all ARRAY limitations: Prehistoric (Sysmac Studio): abVarArray : ARRAY[1..10] OF BYTE ------------------------------------------------------ Normal (All Brands): CONSTANT VAR          c_MAX_NUM : INT := 5; END_VAR; abVarArray : ARRAY[1..c_MAX_NUM] OF BYTE - If is created an Array of FB, the input assistant doen't show the inputs and outputs of this FB when you write "." afbVarModule : ARRRAY[1..10] OF FB_Example fbVarModule : FB_Example afbVarModule[3]. (The assistant NOT shows the interface variables of FB) fbVarModule. (The assistant shows the interface variables of FB) INPUT/OUTPUT FB/Functions limitations: - An input of a Function Block is not allowed to be a Function Block data type, of another for example. Incomprehensible - An RERTUN of a Function Block is not allowed to be a Function Block data type, of another for example, and not allowed use Structure Data Type. Incomprehensible - It is not allowed to use the type of variable ANY (or similar) to be able to make unique functions, and within them, depending on the type of variable (TYPEOF), one thing or another can be done. STRUCT/ DATATYPE limitations: - In a Struct data type it is not allowed to put TON, TOF, R_TRIG or F_TRIG or any other type of FB. - An UNION Data type use a lot of Memory, the variable isn't superposed, the Sysmac creates diferents allocations for each member of UNION Type. Absurd. - In Datatype section, inside to some Namespace, in enumerations... If two members of differents Types of Enumeration have the same name, the Sysmac shows a compilation error. Absurd. Sysmac studio is not able to correctly route the elements of the program INSTRUCTIONS/CODE limitations - There is no possible way to identify the MAC (or serial number, some unique number) of the PLC itself and in the User Program and store it in a Local/Global variable. - The instruction SEL() can't be used in the IF condition, for example: IF SEL(i_xConfigUseVar1, xVar2, xVar1) THEN...... (TThis do a compilation error, another absurd thing, i create a SEL function in a library for each type (because the ANY type is not allowed) := IF SEL_x(SEL(i_xConfigUseVar1, xVar2, xVar1) THEN [AND this.... WORK] - And MORE MORE MORE MORE things [AH, NOT ALLOWED THE USE OF POINTERS] NEEDS TO IMPROVE A LOT Don't tell me "This isn't in the IEC standard" please.. refrain from talking nonsense
  9. Sysmac Studio Improvement Request

    @Crossbow @Michael Walsh @innoaloe , or someone of Omron Company or some Expert User..... I read a lot of your posts. Could you help me to expand this comment and try to the Sysmac Studio will be imporved by Omron developers? Thanks in advance. 
  10. Sysmac Studio Improvement Request

    I wish Sysmac Studio would get things right once and for all ARRAY limitations: Prehistoric (Sysmac Studio): abVarArray : ARRAY[1..10] OF BYTE ------------------------------------------------------ Normal (All Brands): CONSTANT VAR          c_MAX_NUM : INT := 5; END_VAR; abVarArray : ARRAY[1..c_MAX_NUM] OF BYTE - If is created an Array of FB, the input assistant doen't show the inputs and outputs of this FB when you write "." afbVarModule : ARRRAY[1..10] OF FB_Example fbVarModule : FB_Example afbVarModule[3]. (The assistant NOT shows the interface variables of FB) fbVarModule. (The assistant shows the interface variables of FB) INPUT/OUTPUT FB/Functions limitations: - An input of a Function Block is not allowed to be a Function Block data type, of another for example. Incomprehensible - An RERTUN of a Function Block is not allowed to be a Function Block data type, of another for example, and not allowed use Structure Data Type. Incomprehensible - It is not allowed to use the type of variable ANY (or similar) to be able to make unique functions, and within them, depending on the type of variable (TYPEOF), one thing or another can be done. STRUCT/ DATATYPE limitations: - In a Struct data type it is not allowed to put TON, TOF, R_TRIG or F_TRIG or any other type of FB. - An UNION Data type use a lot of Memory, the variable isn't superposed, the Sysmac creates diferents allocations for each member of UNION Type. Absurd. - In Datatype section, inside to some Namespace, in enumerations... If two members of differents Types of Enumeration have the same name, the Sysmac shows a compilation error. Absurd. Sysmac studio is not able to correctly route the elements of the program INSTRUCTIONS/CODE limitations - There is no possible way to identify the MAC (or serial number, some unique number) of the PLC itself and in the User Program and store it in a Local/Global variable. - The instruction SEL() can't be used in the IF condition, for example: IF SEL(i_xConfigUseVar1, xVar2, xVar1) THEN...... (TThis do a compilation error, another absurd thing, i create a SEL function in a library for each type (because the ANY type is not allowed) := IF SEL_x(SEL(i_xConfigUseVar1, xVar2, xVar1) THEN [AND this.... WORK] - And MORE MORE MORE MORE things [AH, NOT ALLOWED THE USE OF POINTERS] NEEDS TO IMPROVE A LOT I don't tell me that it is not in the IEC standard please.. refrain from talking nonsense