Internet PLC Forum

The bitwise not operator, "~", is not handled very well by i-TRiLOGI.

In an arithmetic expression the bitwise not operator is only must be the first thing in the expression to be correctly parsed.  If "~" is not the first thing in the expression, then "~" and the expression that follows must by grouped with parenthesis (I'm guessing that the expression parser is recursive and this why the use of parenthesis makes the unary operator appear to be the first operator since the open parenthesis).

OK. This works:
B = ~A & &hff      ' bitwise not compiles
This fails:
B =  &hFF & ~A      ' Error:Unknown Keyword: "~"
This will compile:
B =  &hFF & (~A)      ' OK

"Bitwise not" is a unary operator and should work on the numeric expression that follows the ~. But the design of TBASIC either got the hierarchy of operators (operator precedence) wrong or was never designed to handle unwary operators correctly. Unary operators should be right below the parentheses in hierarchy and not lumped in with other binary operators (&,|,^).

The negate operator "-" has the same parsing behavior issue as "~".  The negate operator is, also, a unary operator and only works on the numeric argument that follows.  It's operator precedence should be up with the "~".

In both cases, I don't think that you can fix TBASIC, now.  It is way too late.  But you could document the behavior and suggest that the programmer force the evaluation order by using parenthesis around most usages of the unary operators "-" and "~".

The documentation on Bitwise logical operators:
iii) Bitwise Logical Operators: logical operations is perform bit-for-bit between two 16-bit integer data.

There are a major problems with the documentation:
1. All operations are 32 bit not 16 bit for current FMD, Fx, Nano-10 style PLCs.
2. The ~ operator is a unary (not binary) operator and does not "perform bit-for-bit between two 16-bit integer data [values]".  The ~ operator acts on the numeric expression that follows and the result of the operation will be 32 bit.
3. The negate, "-",  operator is a unary (not binary) operator and does not "perform bit-for-bit between two 16-bit integer data [values]".  The - operator acts on the numeric expression that follows the operator.
4. TBASIC's expression parser cannot handle 2 consecutive operators.  if the second operator is - or ~ you must enclose this operator and the expression to the operator's right in parenthesis inorder to get TBASIC to properly evaluate the expression.
5. Mixing up the terms, bitwise, logical and comparison operators.  I think of logical and comparison operators resulting in a value of 0 and not 0.  Bit wise operators result in a 32-bit value with each individual bit being some function of the value(s) and the operator involved.

Best regards,

Gary D*ckinson

I am having problem debugging a trivial program in 7.12.  I am breaking the simulator with the following code:
' FmtFloat - test CF that passes a copy of the the floating value, A#, and the argument, 1, to
'   the StripPlus function with the home that it will return a string in A$

%[1] = StripPlus(A#, 1)

When I try to test this code in the simulator I get the following run-time error message after StripPlus() executes and returns:


"Run-Time Error in Fn #1
 Error:illegal memory access!
 Program has been Halted"


This is the CF, StripPlus:
' StripPlus on entry %[1] is the float to convert, %[2] is the number of decimal digits
'
A$ = str$(%[1], -%[2])

' Now discarad the leading "+" that gets attached to positive values

if strcmp(mid$(A$,1,1), "+") = 0
   A$ = mid$(A$,2,len(A$)-1)
endif

Strip Plus actually does what I want, but I can't figure out what I have done to annoy the simulator.

I can write the code without the use of the "new" parameterized function calls, but I keep thinking there must be a use for this feature.

Do you have any ideas on how I broke the simulator?

Best regards,

Gary D*ckinson

There is a key bit of information that is not spelled out in the TRI documentation of the "StepMove ch, count, r" and the "StepMoveAbs ch, count, r" statements.

The issue has to do with the handling of the "r" argument to these statements. The "r" argument specifies which RELAY is to be cleared by the execution of the statement and then set, later, when the motion of the stepper motor has completed.  If the value of the "count" argument will result in the stepper not moving, then the RELAY WILL NOT be SET.

The problem with the StepMove and StepMoveAbs statements is that certain values for the "count" argument will result in the RELAY "r" not being set and this will result in PLC programs hanging up waiting for this RELAY "r" to be set.

The value that breaks StepMove is when "count" = 0.  The documentation states, "count is a 32-bit integer number which allows you to program the stepper motor to move from -2³¹ to +/-2³¹ .(i.e. about ± 2 x 10⁹) steps".  Notice that the documentation includes the value of "0" in the range of legal values.  Trust me, 0 is not handled the same as the other 2 x 10⁹ possibilities.

The value that breaks StepMoveAbs is when "count" equals the current absolute position.  The documentation for this statement does not mention this fact.

This is the sort of work-around that I use to ensure that all legal values for "count" work the same:


   ' The StepMove statement will not set the BrnCmdCmp RELAY if the
   ' the statement will result in no physical motion of the stepper motor
   '
   ' The fix is to execute the StepMove statement and then
   ' set the BrnCmdCmp RELAY
   '
   StepMove BrineStpprChnl,BrnArg1,BrnCmdCmp
   if (BrnArg1 = 0)
      SetIO BrnCmdCmp            ' set the command completion RELAY
   endif



   ' The StepMoveAbs statement will not set the BrnCmdCmp RELAY if the
   ' statement will result in no stepper motion
   '
   ' The fix is to test if the current absolute position is the same
   ' and the position specified in the argument to StepMoveAbs and after
   ' the StepMoveAbs statement is executed, set the BrnCmdCmp RELAY to indicate
   ' that the statement completed
   '
   if StepCountAbs(BrineStpprChnl) <> BrnArg1
      ' Move stepper to new position
      '
      StepMoveAbs BrineStpprChnl,BrnArg1,BrnCmdCmp
   else
      ' Stepper will not move, so execute the StepMoveAbs statement
      ' to update the stepper motion counters and then set the
      ' command completion RELAY to indicate that the statement has
      ' completed
      '
      StepMoveAbs BrineStpprChnl,BrnArg1,BrnCmdCmp
      SetIO BrnCmdCmp
   endif

[/color]

I know that the StepMove family of statements have been around for a long time.  I'm just new to using them.

Best regards,

Gary D*ckinson

I got bored and decided to do some recreational PLC coding and decided to write a Tic Tac Toe program in ladder logic.  

To make the problem more challenging I decided to attempt to write the code without using custom functions, just 100% ladder logic.  

This is where I got into some issues with the [ILock] and [ILoff] functions.  Turns out that they are not broken, but I was transfixed by the example in section 9.3.5. of the TL6ReferenceManual.  

 [ILock] and [ILoff] turned out to not be very useful for my purposes, but I'd like to know how to program the "Equivalent Circuit".  I have tried everything, but I can't build this circuit with i-TRiLOGI 6 or 7.

Best regards,

Gary D*ckinson

I use the extended file system as a method to update PLC settings via text files. The text files are uploaded to the  PLC via FTP. The PLC code checks for the existence of a new configuration file, periodically.  If a new file is found, the PLC code opens the file for read, extracts the new configuration data and then deletes the file.

The small problem is that it is difficult to tell if a file exists.  The filesystem documentation suggests that reading the value returned from the status(2) function will indicate if the command was successful.  A value of "1" indicates success.

PRINT #8 "<READ Z000.TXT>"   ' Attempt to open file
s = status(2)
[/color][/font]

The call to status(2) will return a 1, to indicate success, under more conditions that you might think. I get a value of 1 for all of the following:

• File does not exist
• File exists and contains no data
• File exists and contains data

It is not possible to determine if a file exists by issuing the "<READ xxxx>" command. In fact I have found no way to determine if a file exists.  It is possible to determine the size of a file after you have "successfully" opened it with the "<READ xxxx>" command using the status(19) function.

Status(19) returns 0 for non-existent files.  Status(19), also, returns 0 if the file exists but hold no data.  For my purposes, an empty file is about as useless to me as a non-existent file.


PRINT #8 "<READ Z000.TXT>"   ' Attempt to open file for read

if status(2) <> 1
   ' File may be already open
   '
   PRINT #8 "</>"         ' Close  file
   return               '   and bail out
endif

if status(19) = 0
   ' File contains no data or it does not exist. You can't actually tell...
   '
   PRINT #8 "</>"         ' Close file
   return               '   and bail out
endif

' we got here because the file exists and contains data
'
' what follows is just test code to allow me to inspect the contents
' of small text files
'
for i = 1 to 26            ' write null strings to A$..Z$
   $$ = ""
next

' read at most 26 strings from the file and place then in A$..Z$
'
for i = 1 to 26
   $$ = INPUT$(8)
   if status(2) = 255
      exit      ' end of file reached,  break out of for loop
   endif
next

PRINT #8 "</>"      ' close file
[/color][/font]

Just some hints on the extended filesystem behavior.

Gary D*ickinson

I am attempting to debug a problem with an FMD88-10 PLC located in another continent.  My client describes the problem as the PLC being "paused".  The behavior that he is describing is consistent with a run-time error.  

I am working to get more accurate information about the issue from my client. But this will take both time and patience on my part.  I seem to not be blessed with much of either...

So in the mean time, I am trying to "instrument" the clients PLC code to log the problem.  I think that there are a few things that I can look for:

• User-defined runtime Error: defining an interrupt handler for run-time errors using the INTRDEF 100, n statement.
• Watch dog timer.  

So here are my questions about INTRDEF to catch a run-time error

• With the INTRDEF approach, how does the custom function "know" what triggered the run-time error?  
• Because CFs on the FMD88-10 do not accept arguments, you can't pass the error info to the CF.  Is the error stuff stored in some undocumented register that the CF might be able to access, say DM[4001]? Oh that would just generate another run-time error....
• Yes, I know that the error info should be displayed on the 4x20 LCD. How does the CF "read" back what was written to the LCD by the PLC firmware?  

I believe that the only way to access this info is via a host link command.  I don't have enough spare serial ports on the FDM88-10 to allow me to wire the ports together. This way I could issue a host link command(s) to read the LCD display and get the strings spit out one serial port and sucked up by the other port.  

Could I achieve this by using issuing a host link command via Ethernet?

• If I could "read" back the error info can I write it to the extended file system to generate an error log?  How much of the PLC code can I expect to run from the run-time error interrupt handler?
• Is there anything that I can do from the real-time error interrupt handler other than to report the PLC?

On the dead-man timer mechanism.  Is there any way that I could log the events that led up to the timeout?  Or does the system just reset and start over?

Best regards,

Gary D*ickinson

I have coded myself into a corner and need some expert advice.

I am using the Fx1616-BA PLC firmware revision 91.1

My client's application uses 3 flow sensors with pulse outputs.  They are connected to PLC inputs 1,3 and 5.  I am using the the High Speed counters 1,2, and 3 to capture the total pulse count for each flow sensor.  Additionally I am using the pulse measurement system to measure either the PulsePeriod on the same 3 inputs.

The incoming pulse frequencies of interest are between 10 and 300 Hz.

For test I am driving the PLC inputs from the PLC's PWM outputs.  This allows me to simulate the behavior of the flow sensors without having to have a 15 HP pump and 460 volt 3 phase electrical service at my home.

I am having a problem with PulseFrequency(1) and PulsePeriod(1).  With a constant input signal at 50 Hz, if I call Pulse Frequency(1) every 100 ms the returned value will not always be 50 Hz, but periodically a value close to 30 Hz is returned.  The 30 Hz measurement shows up about every 20 or 30 measurements and the erroneous measurment lasts for a single call to PulseFrequency(1).

Now what makes this more interesting, is that the PulseFrequency(3) and PulseFrequency(5) measurements are always correct.  I can connect all of the pulse inputs to the same frequency source (remember I am using the PLC's PWM outputs) and only the PulseFrequency(1) values are randomly wrong.

The HSC mechanism calls an interrupt routine when the HSC reaches a programmed limit.  I have instrumented the interrupt routine and have found that with a constant frequency input, that the time between calls to the interrupt routine  is not consistent. This tracks the behaviors of PusleFrequency(1) and PulsePeriod(1).  HSC[2] and HSC[3] do not show these behaviors.

I have tried to duplicate the problem with a minimal PLC program, but have not been able to get a simple program to exhibit the failure.  

Let me tell you what else is going on with this PLC that may have some bearing on the issue and why I can't get a simple program to fail:
1. I am using one of the RS-485 ports to communicate with an external Modbus RTU device.  The Modbus traffic is fairly light.  I am sending out 3 Modbus queries every second, maximum.  Only a single registers is accessed for each query.

2. The RS-232 port is running the most traffic. It is connected to Weintek HMI panel.  The HMI is using the RS-232 link to access the PLC internals.

3. I have turned on the "High Speed Timer" mechanism for 1 TIMER.  I needed a timeout of less than 100 ms.

4. There are no DELAY statements or polling loops in the custom functions. Everything is written to execute as quickly as possible and to execute as seldom as possible.

Do you have any ideas as to what I did in some other life to get into this mess?

I am concerned that there might some sort of issue in your firmware with regards to the handling of the pulse measurement / HSC[1].  I worry about interrupts getting shut off for too long and edge events being missed. I am not having problems with HSC[2] and HSC[3] and that is both "good news" and oddly interesting.

Any suggestions on what to look for or to test for would be greatly appreciated.  If I could get this problem down to a simple PLC program, It would be in the mail.

As always, I am happy to work with you to figure this out,

Gary D*icknson