Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - garysdickinson

Pages: 1 2 [3] 4 5
Technical support / Get_IPAddr breaks Simulator in 7.03 build 6
« on: February 06, 2015, 02:01:06 PM »
I just broke the simulator, again.

This is the code:

print #1 "before offending statement"
Get_IPAddr 1
print #1 "after offending statement"

The Get_IPAddr 1 hangs the simulator and the second print #1 statement never executes.  I assume that the implementation of Get_IPAddr crashed Java.

Get_SubNet, Get_Gateway, Get_SMTP and Get_DNS crash the simulator, also.

I didn't try the Set_xxxx statements to see if they crash the simulator.

The work around is to set a RELAY when running in simulation.  In the  custom functions that have these types of statements, test to see if this RELAY is set and then don't attempt to execute the offending statements.

print #1 "before offending statement"
if !TestIO(Simulation)     ' Execute the following ONLY if not running in simulation.
    Get_IPAddr 1
print #1 "after offending statement"

I think that a possible workaround for simulation is to use the status(5) function.  On physical hardware, this function returns a non-zero value related to firmware revision.  On the simulator it returns 0.  I can use this fact to conditionally skip code that breaks the simulator.

It would still be nice if the Get_xxxx stuff didn't break the simulator.

Gary D.

Technical support / str$ handiling of negative float values
« on: January 14, 2015, 05:36:12 PM »
Hi all,

I was sort of surprised by the behavior of the str$(x#,w) function when x# was a negative value.  -3 can be displayed as -2!

This experiment was only run in the simulator in i-TRiLOGI V 7.03 build 6.  I did not run this code on actual hardware, sorry.

This is my test code:

' Display Float
i = -3
while (i < 4)
   i# = i
   print #2 "Value: ";i;         ' print integer value
   print #2 " "; str$(i#);      ' float with default formatting
   print #2 " "; str$(i#,-3);      ' float with 3 decimal points
   print #2 " "; str$(i#,0)      ' float rounded to nearest integer

   i = i + 1


This is what I saw:

Value: -3 -3.0000000 -2.999 -2
Value: -2 -2.0000000 -1.999 -1
Value: -1 -1.0000000 -0.999 0
Value: 0 +0.0 +0.000 0
Value: 1 +1.0000000 +1.000 1
Value: 2 +2.0000000 +2.000 2
Value: 3 +3.0000000 +3.000 3

I checked the bit pattern of the floating point values and saw that they represented exactly -3, -2 and -1, but if I used the str$(x#, w) statement, the strings did not represent whole integer values.

The str$(x#,0) format, which is documented as "Rounded to the nearest integer" thinks that the closest integer to -3 is -2???  I sort of think that the nearest integer to -3 is actually -3.

Am I expecting too much?

Also another fun fact about TBASIC.  The following code will not work as expected:

for i = -3 to 3
   i# = i
   print #2 "Value: ";i         ' print integer value

Oh, I expected that the code between the for and next keywords would be executed for values of "I" from -3 to 3...

Interestingly, "I" is initialized to &H0000FFFD which is not -3 (for a 32-bit signed integer).  This results in the initial value of "I" being greater than the limit value of 3, so the code between for and next keywords is not evaluated.  If "I" had been a 16-bit signed value then %HFFFD is -3.  I am guessing that for/next can only work with unsigned values between 0 and 32767.  I'm guessing that this is real old code "feature".

Best regards,

Gary D

Technical support / HSCDEF fn_num issue with i-TRiLOGI 7.03
« on: January 07, 2015, 04:48:00 PM »
The HSCDEF statement does not tolerate the "name" of the custom function but requires the numeric constant for the 2nd argument.  This seems like an oversight.

The following code snippet will not compile.  "Accumulate" is the name of custom function #4. No error message is generated indicating that this syntax is unacceptable.

HSCDEF 1, Accumulate ,9999

This code will compile:

HSCDEF 1, 4 ,9999

It would be nice if the compiler could indicate the failure.  

It would be better if the HSCDEF statement could accept the the "name" of the custom function.

Best regards,

Gary D.

Technical support / i-TRiLOGI V7.03 User interaface problems.
« on: October 23, 2014, 09:59:51 PM »
I've encountered a bunch of issues with the user interface in V7.03
  • Define Variable Names.  It is nearly impossible to delete a row in the table. Right clicking to get the pop up menu and selecting "Delete Row" does not seem to work.
  • Cut, Delete Ladder logic commands that bring up the dialog that has the "From Circuit #" and "To Circuit #" boxes has problems if you change the "From Circuit #" to anything but the current Circuit number.  Odd things get deleted.  If you have to scroll down the ladder logic to verify a ladder logic line number the cut/delete commands will usually delete some random stuff. This is a very scary behavior.
  • Ladder logic editor problems with the "Select a Sequencer" window.  If you press "enter" to confirm that you want the highlighted Sequencer 1..8 will insert a contact for SeqN:0 without bringing up the "Enter Step #(0-31) dialog.  The only way to get the "Enter Step # (0-31) dialog is to left click on the "select a Sequencer" window.
  • On a ladder rung that ends with {dCustF} it is not possible to bring up the "Edit Label Name" dialog.  To change the name you either have to delete the {dCustF} terminator and enter a new one or you have to add a new one in parallel and delete the original.  The "Edit Label Name" dialog works for most other contacts and terminators.
  • The "Edit" menu hints that Ctrl-X can be used as a short cut for Cut Circuit.  Ctrl-X seems to be ignored by the ladder logic editor.
  • The use of the Delete key in the ladder logic editor (to delete a contact) affects the state of the text editor.  If you use the Delete key, then the text editor changes behavior to overwrite mode.  To fix this you have to press the "Insert" key while in the text editor (custom functions).  This is annoying and messy.
  • If you use "Find & Replace I/O Labels" in the ladder logic, it will take you to the rung that contains the label. If you then attempt to scroll up or down in the ladder logic you are taken back to the first rung in the logic.  To keep this from happening after using the "Find" I click the "Circuit # nn" button and enter the circuit number that the is shown on the screen, now the screen allows me to scroll.

Just add 'em to the list.

Gary D.

Technical support / Correct Usage of #defineLocal, i-TRiLOGi V7
« on: October 22, 2014, 10:39:08 AM »
OK, you added a new "keyword", #defineLocal.  How do you use it?
  • The text "#defineLocal" is highlighted by the syntax highlighter.
  • Clicking on #defineLocal" does not bring up any "keyword helps"
  • #defineLocal" is not in the list of "keyword helps"
  • The TL7ReferenceAddendum.pdf mentions the #defineLocal, but gives no hint or example of how to use it.
Ok.  So I'm taking guesses.  I wrote the following custom function (one of a series of tests):

#defineLocal ILocal %[1]%

For ILocal = 1 to 10
   print #1 ILocal

I wrote ladder logic that could invoke the custom function (I know about the compiler optimization for orphaned functions).

If I run the "Compile Only" option, the code compiles without complaint (no syntax error).

If I comment out the #defineLocal line, the code fails to compile (as it should).  This suggests that my usage of the #defineLocal is pretty close to what the compiler expects.

If I click on the "Run (All I/O Reset) menu, the simulator does not run and no error messages are presented.  The presence of #defineLocal breaks the simulator!

OK.  So how was this #defineLocal supposed to be used?

Gary D.

Technical support / Java and i-TRiLOGI
« on: October 03, 2014, 10:02:11 PM »
I know this is an old subject, but it keeps me awake at night.

C:\Program Files\Java\j2re1.4.2_19\bin\java.exe  just is not happy with current windows operating systems.    i-TRiLOGI windows get messed up if you move them, i-TRILOGI messes up Outlook and other programs when run this ancient unsupported versions of Java.

If I force i-TRILOGI to run with current Java, I have none of these problems.

I've attached a sample of what happens with j2re1.4.2_19.  If I run the i-TRiLOGI stuff with the current java, I don't have all of these problems.

In the old days I could edit the "TL6.BAT" file and newer versions of Java to run.  This file is still present in the install directory but is no longer used.

Is there anyway with your new TL6/TL7 launcher to select what version of Java is to be used?

I'd love to use a version of Java that works with Win7 64 bit for the development tools.  I'm OK with the old Java for TLServer (it doesn't really have a user interface).

Sorry to bring up this old festering issue,

Gary D

Technical support / RESTART Statement and New IP address
« on: September 28, 2014, 02:39:28 PM »
I'm struggling with the RESTART statement. I'm attempting to have the PLC set/change it's own IP address.  The documentation states:

"To perform a cold reboot of the PLC from within a CusFn. The effect is identical to a power-on-reset except that you execute this command without turning OFF power to the PLC.
RESTART may be necessary for some changes to take effect, such as for the PLC to assume new IP address after executing the SET_IP command."

My observations are that The RESTART statement does not do the job.  I find that I still must power off the PLC to get the IP to change.

I am using 2 custom functions for my debug code, "Init" once at 1st.Scan and displays the current IP address using the new Get_IPAddr.  The second custom function is "ToggleIP" it runs only in response to an INPUT and attempts to change the IP address back and forth between "" and "".

Init looks like this:

' Init
Get_IPAddr 1         ' Get PLC IP addres in DM[1..5]
A$ = str$(DM[1])+"."+str$(DM[2])+"."+str$(DM[3])+"."+str$(DM[4])+":"+str$(DM[5])

SetLCD 0,1,"\01"      ' Clear LCD display
SetLCD 0,1,Chr$(12)   ' No cursor
SetLCD 1,1, "PLC IP Address:"
SetLCD 2,1, A$
ToggleIP looks like this:

' ToggleIP
Get_IPAddr 1         ' Get PLC IP addres in DM[1..5]
A$ = str$(DM[1])+"."+str$(DM[2])+"."+str$(DM[3])+"."+str$(DM[4])+":"+str$(DM[5])

SetLCD 0,1,"\01"      ' Clear LCD display
SetLCD 0,1,Chr$(12)   ' No cursor
SetLCD 1,1, "Current IP"
SetLCD 2,1, A$

Delay 4000      ' kill some time so the LCD can be read

' Toggle  IP address between and
if DM[4] = 16
   DM[4] = 17
   DM[4] = 16
A$ = str$(DM[1])+"."+str$(DM[2])+"."+str$(DM[3])+"."+str$(DM[4])+":"+str$(DM[5])

SetLCD 3,1, "Next IP"
SetLCD 4,1, A$
Delay 4000      ' kill some time so the LCD can be read

Set_IPAddr 1   ' Set new IP address

RESET         ' Update flash memory that holds the IP variables

RESTART         ' Force a cold reboot to restart the PLC and actually configure the
            '  PLC to the changed IP address.


If I toggle the INPUT, I can see on the LCD, that the ToggleIP custom function runs.  I am convinced that the RESTART statement does restart the ladder logic scanning mechanism. However, the IP address shown on the LCD after the RESTAT, is not the actual IP address of the PLC.  The actual IP address is unchanged!

If I power down the PLC, then the PLC's IP does change to match the value on the LCD.

This is my evidence that RESTART is not the same the ultimate reset caused by killing power to the PLC.

Hardware info:  FMD1616 r82A

What am I missing?

Gary D

Technical support / Controlling PLC via Web Browser, LCD Display
« on: September 03, 2014, 01:56:13 PM »
I've been working with the "Controlling PLC via Web Browser" scripts that is described in the "Frequently Ask Questions" portion of forum.

I've noticed that the LCD portion of the web page uses a variable pitch font and left justifies the LCD strings. This makes the Web version of the 4x20 display not look very much like the LCD.

I found that I could fix the font issue by adding the line to this section of the "0-C001-01.html" file:

.LCDline {
   background-color: #FFFFCC;
   border: solid 1px #FFFFCC;
   color: #000000;
   font-family: Courier;
   position: absolute;

So now my question, "Is there a way to specify that the LCDline text is not to be stripped of white space and left-justified?"

The attached jpeg shows the web page and what the LCD should look like.

Gary D

Technical support / Is there a <FTPAPPEND> command?
« on: August 22, 2014, 09:43:49 PM »
I've been using the <FTPUPLD xxxx> network command to upload data files from the PLC to my client's FTP file server.  My client would like the PLC to be able to append data to an existing file via FTP.

I've explained that I do not believe that there is an "undocumented" FTPAPPEND network command.  

So the question is, "have I been telling my the truth?"

Best regards,

Gary d

Technical support / Type checking problem in i=TRiLOGI V6.48
« on: August 08, 2014, 05:19:30 PM »
I'm getting syntax errors while I compile the following:

for i = 1 to 8
   print #1 Load_EEP$(i)

but this works:

for i = 1 to 8
   A$ = Load_EEP$(i)
   print #1 A$

I think that your syntax checker for the Print #n statement has some type checking issues.

I've attached a screen shot showing the error messages

Best regards,

Gary D.

Technical support / NS TCPCONNECT Behaviors
« on: July 28, 2014, 03:55:24 PM »
I have been testing the behavior of the TCPCONNECT tag to access network timeservers.  The test is being done on an FMD1616 PLC with firmware r82A.

This post is more to provide information on how things work then to ask a question.  

My observations on the behavior of this command are as follows:
  • The TCPCONNECT tag is non-blocking. The execution time of the statement,  print #4 "<TCPCONNECT>" is about 450 us.  I have not observed it to exceed 500 us.
  • Polling for command completion using INPUT$(4) can fail.  It is possible to poll forever and not receive either a response from the remote device that you are attempting to connect to nor an error message from the PLC TCP/IP firmware.
  • If the PLC TCP/IP firmware does return an error message, this message is received iin 2 seconds or less. This seems to suggest the the TCP/IP firmware does have a 2 second timeout mechanism.
  • The results with polling using INPUT$(4) can be different if on-line monitoring is being used vs. the PLC being physically disconnected from the Ethernet bus.
  • Status(3) behavior. Immediately after issuing the TCPCONNECT tag, Status(3) returns a value of 0 indicating that the command is being processed.  Status(3) will return a value of 1 when a TCP/IP connection has been established. The actual response message from the server is not available for 40ms after Status(3) indicates a TCP/IP connection.
  • In the event that the timeserver drops the connection, Status(3) will go back to a value of 0, but there is no response message from the server and the PLC TCP/IP firmware does not post an error message.  

This is the PLC test code that I was using to make these evaluations and measurements

' Demo of NIST command behavior
' the integer variables a,b,c,d and e are used to calculate elapsed time
d = 0
e = 0
A$ = "<TCPCONNECT>"   'Connect to time server

print #1 ">>> "+A$
a = status(21)               ' timestamp: Start
PRINT #4 A$                   ' Send TCP command
b = status(21)               ' timestamp: Command overhead
Print #1 "         Status(3): "; status(3)

' poll for message
i = 3000                  ' max poll time in ms
A$ = INPUT$(4)
while i and (len(A$) = 0)
   delay 1

   ' this code is looking for status(3) to go from 0..1
   '  indicating that the there was a connection to the
   '  time server was established
   if (d = 0)            
      if (status(3))
         d = status(21)

   ' this code is looking for status(3) to go from 1..0
   '  indicating that the connection to the time server
   '  was dropped
   if (d and (e = 0))            
      if (status(3) = 0)
         e = status(21)

   A$ = INPUT$(4)
   i = i -1
c = status(21)               ' timestamp: Command complete

print #1 "     Print #4 time: " + str$(b-a)
if (d)
   print #1 "      Connect time: " + str$(d-b)
   print #1 "Failed to Connect"
if (e)
   print #1 "Connection dropped: " + str$(e-b)

print #1 "    INPUT$(4) time: " + str$(c-b)
print #1 "      Cmd Response: " + A$
A$ = INPUT$(4)
print #1 "      Cmd Response: " + A$
Print #1 "         Status(3): "; status(3)

Print #4 "</>"               ' close connection

The print #1 statements send messages over a serial port that was used to monitor the behaviors.

The following are the descriptions of the test cases, the captured results and my annotations:

   This is what I observed for a successful connection:

         Status(3): 0
     Print #4 time: 4344         <-- non-blocking TCP command
      Connect time: 434091         <-- TCP connected in 43.4ms
    INPUT$(4) time: 856717         <-- response avialabe in 85.7ms
      Cmd Response:
      Cmd Response: 56866 14-07-28 19:31:53 50 0 0 906.4 UTC(NIST) *
         Status(3): 1            <-- TCP still connected?

   Forced connection failure.  Ethernet cable disconnected. Online monitoring
   not used.

         Status(3): 0
     Print #4 time: 4394         <-- non-blocking TCP command         
Failed to Connect               <-- TCP did not connect
    INPUT$(4) time: 19739621      <-- 2 second timout
      Cmd Response: ERR:01-Connect Fail   <-- useful error message
      Cmd Response:
         Status(3): 0            <-- TCP not connected

   Forced connection failure.  Online monitoring established and then the
   Ethernet cable was disconnected.

         Status(3): 0
     Print #4 time: 4323         <- non-blocking TCP command
Failed to Connect               <-- TCP did not connect
    INPUT$(4) time: 30026965      <-- This is test firmware timout
      Cmd Response:               <-- No error message from TCP/IP stack
      Cmd Response:
         Status(3): 0

   This is what I see if we use a valid URL with wrong port number:

         Status(3): 0
     Print #4 time: 2487         <-- non-blocking TCP command
Failed to Connect               <-- TCP did not connect
    INPUT$(4) time: 4064         <-- very little delay to error msg
      Cmd Response: ERR:03-Invalid URL   <-- useful error message
      Cmd Response:
         Status(3): 0

   This is what I see if the server initially connects then drops the connection
   without sending the time response:

         Status(3): 0            
     Print #4 time: 4476         <-- non-blocking TCP command
      Connect time: 440977         <-- 44ms to TCP connection indication
Connection dropped: 1262044         <-- 126ms to TCP connection loss
    INPUT$(4) time: 30023768      <-- timeout in test code
      Cmd Response:               <-- No error message
      Cmd Response:
         Status(3): 0

Gary D

Technical support / Zombie break points.
« on: July 27, 2014, 06:51:02 PM »
I noticed that if one or more break points are marked in a custom function and then that custom function is either:
  • Cleared using the "Clear Custom Function" choice in the "Edit" pull down menu
  • Erased by highlighting all of the text and then deleting in the custom function editor
  • Shifted up or down from the "I/O Labels" right click "Shift I/O"

That the breakpoints remain in erased functions.  There is no text in the erased functions, just zombie breakpoints. These zombie break points can be "found" but not cleared.  They just won't die.

Shifting the custom functions up/down causes these zombie break points to appear in functions that don't have break points.  Not only can the zombies not be killed, but they can reproduce and infect functions around them!

I have found that I can remove the zombie break point in custom function #2s if:

  • Create a custom function #3.  This function must have more lines of text then the position of the last break point in #2.
  • In the "I/O Table" editor click on custom function #2 and then shift this function up.  This causes the text of the break points in the "old" #2 to now be associated with the text of the old #3 and everything is in the new custom function #2
  • Now remove the break points from function #2
i-TRiLOGI Version 6.48 build 01

The attached file shows a custom function that had 2 breakpoints, then the text was removed with the "Clear Custom Function" dialog. The pink highlighted zombie break point has been "found", but can't be removed.

Gary D.

Technical support / Blocking Network Commands?
« on: July 25, 2014, 04:21:44 PM »
I'm working with a FMD1616-10 with firmware r82A

I've noticed that the network DNS command:

PRINT #4 "<DNS>"

Has a blocking behavior.  The PRINT #4 command does not return until the TCP command has completed (or failed).

I've used the following code to verify this behavior:

' Demo of DNS Blocking command behavior
Print #4 "</>"

A$ =  "<DNS>"
a = status(21)               ' timestamp
PRINT #4 A$                   ' Send DNS command
b = status(21)               ' timestamp
A$ = INPUT$(4)
while (len(A$) = 0)
   A$ = INPUT$(4)
c = status(21)

print #1 " Print #4 time: " + str$(b-a)
print #1 "INPUT$(4) time: " + str$(c-b)
print #1 "  Cmd Response: " + A$

This is what I see when the DNS command is successful:

 Print #4 time: 520132
INPUT$(4) time: 1812
  Cmd Response:

This shows that the Print #4 command took about 52 mS.  The entire loop polling for command completion took about 180 uS. It appears that this is no reason to poll for the response from the DNS command

This is what I see when the DNS command fails because I pulled the Ethernet cable from the PLC (command time out):

 Print #4 time: 20013005
INPUT$(4) time: 2012
  Cmd Response: ERR:07-DNS Unresolvd

I observe that the Print#4 statement took 2 seconds to fail.  The issue is that the ladder logic is locked up for 2 seconds. The loop to check for the response took about 200 uS. This adds to the evidence the that Print #4 command is blocking and does not complete until either the command completes or the TCP/IP stack times out.

So I have the following questions:

1. Is there a special setting to make the Print #4 command non-blocking?  I would like to have the PRINT #4 command execute quickly and periodically poll for the result.  Non blocking, yes?

2. Is there a very fast way to determine if the PLC can communicate with the network without locking the PLC up for 2 seconds? Ping?

3. Do other TCP commands have this same blocking behavior?  I'm would like to be able to connect to FTP servers and time servers without locking the PLC up until stuff completes.

4. Why does the Nano-10 manual programming example  for "DNS command:" use polling when the commands blocks? No need to poll.

PRINT #4 “<DNS>“
FOR I = 1 to 10000
  A$ = INPUT$(4)
  IF LEN(A$) <> 0
    SETLCD 1,1,” IP=”+A$

Gary D.

Technical support / CAN bus support on Super PLCs?
« on: July 16, 2014, 11:54:41 AM »
I have been working with the Fx1616-BA super PLC.  I noticed that there is a connector and a socket for a CAN bus transceiver on the main PCB.

Will support for CAN bus be added to the super PLC family?

I have a customer that is asking?

Best regards

Gary D.

Technical support / Missing Help Files for i-TRiLOGI V6.47 Build 07
« on: July 05, 2014, 02:12:10 PM »
When running i-TRiLOGI V6.47 Build 07 the following files are missing (not installed) for help on the STR$ function:

   C:\Program Files (x86)\TRiLOGI\TL6\public\Help\tbasic\strfloat1$.htm
   C:\Program Files (x86)\TRiLOGI\TL6\public\Help\tbasic\strint$.htm

If I run i-TRiLOGI V7.01 Build 03 the files have been installed:

   C:\Program Files (x86)\TRiLOGI\TL7\public\Help\tbasic\strfloat1$.htm
   C:\Program Files (x86)\TRiLOGI\TL7\public\Help\tbasic\strint$.htm

I suspect that the problem is that the V6.47 TRiLOGI is using the V7.01 HTML file for the STR$ command (which includes support for floating point values) rather than the HTML version that only supports integer variables.

This is the text that I "see" when using V6.47:

STR$ (n)  & STR$ (n, d)
These two functions work differently when n is an integer type and  when n is a float type.
 Please select the function of the relevant type below:

STR$(x#, w) Where n is a Floating Point constant or variable
STR$(n, w) Where n is an Integer constant or variable

By the way the help for PIDCompute and PIDdef  7.01 does not indicate that the functions such as PID compute require floating values for many of the arguments.  This is mentioned in the "TL7ReferenceAddendum".

In general the functions that were added to support floating point variables such as: ARCCOS, ARCSIN, ARCTAN, ... do not mention that the functions accept or require float type arguments nor does it specify the return type of the function.  One can guess at the argument types, but I would think that the point of documentation is to make this obvious.

I know these are little things, but I thought you'd like to know.


Gary D.

Pages: 1 2 [3] 4 5