Internet PLC Forum

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.

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.

I've run into some difficulty attempting to change values in the EEPROM string data area.  The target PLCs are the Nano-10 and FMD series.

The goal was to write a null string, "", into the EEPROM string data area without having to write, download and execute a .PC6 program.

The first failed attempt was to use Host-link commands in the form of "@01W$000200*<cr>"  This failed with the error message, "@01ER56*<cr>" being returned from the PLC.  It seems that this host-link command is not capable of dealing with a "" message.  

I tried all sorts of games to send a send a single character string where the value of the this character was a &H00.  Host-link commands are not happy with unprintable ASCII.

The second attempt was to use the "PLC Data EEPROM Manager" that was part of i-TRiLOGI V6.45. This program can correctly recognize a null string stored in the EEPROM string data area but is not capable of writing a null string.

As an example if the EEPROM string memory contains a null string for $2, the EEP Buffer window will show the following:

$1,FMD    r79A
$2,
$3,hello
[/color]
If the "Save Buffer to File" button is pressed the .csv file that is created looks like this:

$1,FMD    r79A<LF>
$2,<LF>
$3,hello<LF>
<CR><LF>
[/color]
Now I will change the value of the EEPROM $2 is via a PLC program with the following code:

save_EEP$ "Test String", 2
[/color]
The EEP Buffer window will show:

$1,FMD    r79A
$2,Test String
$3,hello
[/color]
If the .csv file that was created when $2 was a null string, "", is loaded back into the String Buffer Window and then the YELLOW button labeled, "Write EEP Buffers to PLC", then $2 is not changed to a null sting, "". OOPS!

OK now the condensed version of my complaint:

1. The PLC Data EEPROM Manager is capable of reading a null string, "", from EEPROM but is not capable of writing a null string back into EEPROM.  This is very non-symmetrical behavior and is surely a programming error that could be fixed.

2. The Host-link command to write strings to EEPROM is incapable of dealing with a null string. This command has problems with many strings that are legal in TBASIC.  This command can only write strings that are one or more characters in length and do not contain any unprintable ASCII characters.  I don't think that you can fix this as this would require firmware changes.

3.  I suspect that problem #2 is the root cause of why the  EEPROM Manager can't write a null string.  I believe that the EEPROM Manager can be fixed by having it use the "Write EEPROM Integer Data" host link command to force a value of &H00 at the starting location in EEPROM for the specified string.

4. I have a minor gripe with the the .csv format written by the EEPROM Manager.  Microsoft EXCEL will read this file successfully, so my soap box is pretty small.  The gripe, is that the file is created with inconsistent end of line characters.  Most of the lines are terminated  with a line-feed character (UNIX format) but at least two of the lines in the file use the 2 character sequence of carriage return then line-feed (DOS format).  I sure that this is just messy Java programming.

Best Regards,

Gary D.

I have been working with the ExtendedFilesystem.PC6 program to provide file uploads to an FTP fileserver.

I've noticed that the first character of the first response from the FTP server is discarded.

I have modified the ExtendedFilesystem.PC6 program to provide additional debug by echoing all of the commands to Port #1 (RS-232 on the FMD-1616 PLC) and capturing both the commands the responses from INPUT$(4) (TCP/IP) port.

In the following example, lines prefixed with ">>> " represent the commands, "<<< " are the responses and those lines that start with "*** " are status or other information.

This is typical of what I am seeing:


>>> <TCPCONNECT marat.com:21>
*** FTP Connection Established
>>> HELP
<<< 14-The following SITE commands are recognized
<<<  CHMOD
<<<  IDLE
<<<  UTIME
<<< 214 Pure-FTPd - http://pureftpd.org/
>>> USER anonymous
<<< 230 Anonymous user logged in
>>> PASS
<<< 230 Any password will work
>>> CWD FTPFolder
<<< 250 OK. Current directory is /FTPFolder
>>> TYPE I
<<< 200 TYPE is now 8-bit binary
[/color]

Look at the line following ">>> HELP" and notice that it begins with "14-".  It should begin with "214-".  If I access this same FTP server with FileZilla, I see the correct response messages.  "14-" is not a correct value for the FTP protocol.

If I eliminate the FTP "HELP" command then then first command that is issued to the FTP server is "USER xxxx".  This is what I see:


>>> <TCPCONNECT marat.com:21>
*** FTP Connection Established
>>> USER anonymous
<<< 30 Anonymous user logged in
>>> PASS
<<< 230 Any password will work
>>> CWD FTPFolder
<<< 250 OK. Current directory is /FTPFolder
>>> TYPE I
<<< 200 TYPE is now 8-bit binary
[/color]

You will notice that now the response to the "USER" command starts with "30 " instead of the correct pattern of "230 ".

I suspect that this is a firmware issue.  I am testing with an FMD-161 r79A PLC.

I'm guessing that your firmware discards the sign-on message from the FTP server.  This may be a clue as to why the first character of the response to the first FTP command is lost.

This is what I see using FileZilla on the same FTP Server:

Status:   Connecting to 180.74..:21...
Status:   Connection established, waiting for welcome message...
Response:   220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Response:   220-You are user number 1 of 10 allowed.
Response:   220-Local time is now 13:27. Server port: 21.
Response:   220-IPv6 connections are also welcome on this server.
Response:   220 You will be disconnected after 10 minutes of inactivity.
Command:   USER anonymous
Response:   230 Anonymous user logged in
[/color]

Best regards,

Gary D.

Over the years you have been adding things to i_TRiLOGI to improve the functionality and to improve the readability of the PLC code.

I really like the #define (pre-processor) mechanism, a lot.  

Since you added the ability to shift I/O names up/down in the I/O Tables this has had the unintended side effect of breaking code.

The access to Counter/Timer Set Values and Present Values can only support an integer constants or variables for the argument n:

GetTimerSV(n)
SetCtrSV(n)
TimerPV[n]

GetCtrSV(n)
SetCtrSV[n]
CtrPV[n]

It would be very nice if the "name" of the COUNTER or TIMER that is used in the I/O Table could be used in place of "n".  The TBASIC parser (tokenizer) allows both integer constants as well as integer variables for the argument "n".

This way if you wrote code that had a COUNTER named "EventCtr" that was physical counter #10 in the I/O table then you could access the present value of this counter in a custom function with code like this:

A = CtrPV[EventCtr]

rather than like this:

A = CtrPV[10]

I think that this would be pretty simple for your parser to handle.  You are generating a symbol table that relates names to I/O #'s because you can handle statements like:

If TestIO(EventCtr) ...  where EventCtr is a name in the I/O of a COUNTER.  The TBASIC parser (tokenizer) will accept integer constants, integer variables and symbols used in the I/O table as the argument "n".  See it can be done!!!

Because you have added the ability to shift I/O Table elements up/down it is very easy to break any custom function that uses

A = CtrPV[10]

If it could be written as

A = CtrPV[EventCtr] then the I/O shift would not break the code.  There is also a possibility that the code may be a bit easier to understand and maintain.

Part of what made me think of this is that I am working with your example program, "ExtendedFileSystem.PC6".  The custom function, ConnFTP,  has code that accesses the PV of TIMER #2.  This timer is not defined in the I/O table.  It is not obvious by looking at the I/O Table that this TIMER is being used at all.  It is equally mysterious when looking at this code with on-line monitoring when a TIMER with out a name wakes up and runs through values.  I do 100% understand what the custom is using TIMER #2 to accomplish.

Best Regards,

Gary D.

Is it a know problem with Nano-10 +r73 that the RSHIFT command does not function as documented on actual hardware?

If I initialize DM[] as follows:
DM[1] = &H8000
DM[2] = &H8000
DM[3] = &H8000
DM[4] = &H8000

Then issue:
RSHIFT DM[1],4       ' shift one bit right DM[1..4]

This is what I see:

DM[1] = &HC000
DM[2] = &HC000
DM[3] = &HC000
DM[4] = &HC000

This is what I expected:
DM[1] = &H4000
DM[2] = &H4000
DM[3] = &H4000
DM[4] = &H4000


I am not seeing the least significant bit being shifted into the most significant bit of the lower numbered variable.

What I am seeing is a shift within each 16 bit register that is mostly a propagation of the signed bit.  

For RSHIFT to be useful it CAN NOT be a 16-bit unsigned shift.

In the simulator the RSHIFT command executes as documented.

If I purchase a new Nano-10 is this problem resolved?

Gary D

Gentlemen,

I have been working  with Mr. R. Tito to interface a FMD series PLC to a GSM MODEM using the RS-232 port.

We have been able to solve most of the interface issues.  We have been able to get a system that handles a reasonable subset of sending/receiving SMS text messages.

I have run into a problem that I can not solve with clever use of TBASIC and ladder logic.  The GSM MODEM can and will send responses that exceed 256 characters.  Unfortunately, the PLC does not appear to support any sort of hardware handshake (RTS or DTR) to prevent the GSM MODEM from sending more characters than the PLC receive buffer can handle.

The typical GSM MODEMs do support hardware handshake on their RS-232 ports to prevent buffer overrun.

Have I missed something in my understanding of the PLC RS-232 behavior?  

Is there some semi-secret system command or jumper that could be set to get the PLC to indicate when it can not accept serial data without corrupting the receive buffer?


Thanks,

Gary D.

The CHR$(n) function is incorrectly documented:

"To convert a number n into its corresponding ASCII character. n must be a numeric constant (0 to 255)"

The range of n is limited to 1..255.  This limitation is consistent with most variants of BASIC. The value of &H00 is used to mark the end of a string in many versions of BASIC.  Your documentation for ASC(x$,n) hints that this is the case for TBASIC.

If n is set to a value of 0, it will break the simulator in TRiLOGI V 6.40 build 02.

The following code will compiles w/o error but fails during simulation.  No error message is issued by the simulator, but the 2nd line of code is not executed (A is not set to 255).


A$ = chr$(0)      ' illegal value for chr$()
A = 255           ' this line of code does not execute


Just add it to your list of small things.

Gary D.