Internet PLC Forum

Thanks for reminding me about the INTRDEF 100,n,1 stuff.

It is not documented anywhere that I have found.  

The help info for INTRDEF from within the CF editor looks like this:

Enable Interrupt Input channel ch.
ch = interrupt channel number (pls refer to PLC installation guide)
fn_num= Custom Function number to execute when interrupt pin changes according to the defined edge. This is the Interrupt Service Routine ISR.
edge = Positive number means rising edge-triggered. 0 or negative number means falling-edge triggered.


No mention of Undefined interrupt trap (ch# 100).

The "help" mentions the "PLC installation guide".  However your website's product documentation section doesn't have any installation guides.

There are user manuals on the website. I have gone through each of the user manuals there is no mention of INTRDEF with ch# 100.

The TL6 Reference Manual does give some generic info on INTRDEF, but suggested that the Ch argument is from 1..8 (physical inputs) only.

The TL7 addendum makes no mention of INTRDEF.

Is there any change to TBASIC/PLC firmware that would allow a user-defined interrupt CF to determine, what interrupt caused the exception?  Or the CF number that was executing when the exception occurred?

Gary D

You are correct that instead of "Installation Guide" they should be called "User Manual".  I just checked - For FMD88-10 and FMD1616-10 You can find the INTRDEF 100, n mentioned on page 1-14 and 9-2.  There is a syntax error here - it should have been "INTRDEF 100, n, 1" otherwise it wouldn't compile. But you are correct that this is not mentioned in Fx2424 and Fx1616 User Manual and we will get this fixed.

Thanks for the report. It is indeed the first time we receive report of this issue.  We will check if we should fix this and let it accept 0-255 or just change the documentation to state that it is valid between 0 and 127. Few people use more than a few of these GOTO labels inside a custom function so 0-127 would be sufficient.

Thanks again.

Thanks for reporting the test.

You may have guessed it already - The TBASIC firmware would reset the WDT when you run the DELAY function so multiple DELAY functions executed one after another is not going to trigger the WDT reset.

Our thinking is that if you put a DELAY 1000 or even DELAY 10000 you probably know what you are doing,  and we don't want to jump the gun by forcing a WDT reset on such actions.

Basically we intend for the WDT reset to happen only when something really unexpected take place and we did not have the intention of enforcing the programming discipline on the programmer to remember to do WDT reset everywhere if they choose to enable the WDT.  

We think many programmers probably develop their applications program without the WDT initially and come production time they decide to add in the WDT. If the firmware doesn't reset WDT in most of the programming construct automatically, that will mean the programmer will be required to check the program carefully to add the reset WDT function everywhere that the program may spend too long in a certain loop. Even in the best case there is still a good chance that the programmer may miss out a function or two during their inspection and the machine then get shipped to the customer... now their customers will report that the controller seem to reboot itself every now and then for no good reason - we are probably going to get an earful from irritated programmers...

We hope the above explanation make sense. Thanks for the feedback.

Sorry for the late reply due to all the holiday season lethargy...

The firrmware performs WDT reset when the program is inside a FOR.. NEXT loop. Some FOR NEXT loop may take longer than the WDT time-out period to execute and we didn't want the processor to be reset by the WDT when  the program is performing a legitimate FOR..NEXT loop that takes a long time to complete.

We believe more applications could be caught by an unexpected WDT reset if we don't automatically perform a WDT reset inside a FOR NEXT loop.  It is more likely for spaghetti GOTO statements inside a function to go ashray than a structured FOR... NEXT loop or WHILE..ENDWHILE loop, and hence we don't automatically perform WDT reset for the structured loop. We are not purist in this sense but just trying to minimize the potential problem that user may encounter if we let WDT expires inside a structured loop and depend on the programmer to reset the WDT in a timely manner.

You can use the INTRDEF 100, n, 1 to set an undefined interrupt trap. n is the custom function number. This command is described in the help file for INTRDEF.

Yes you can use both WDT and the undefined interrupt trap at the same time. That allows you to catch the undefined interrupt and you can decide if it is safe to let the execution resume or force a processor reboot.

Yes but you need to run a server software on your PC that can receive data from a connected TCP/IP device.

The simplest server for such an application would be the TLServer that you already have. You need to run the TLServer and the PLC would connect to the TLServer IP address and use the <REMOTEFS> tag.

You can refer to the sample program in "TestEthernet.PC6" that you can find in the following folder:

C:\TRiLOGI\TL6\usr\samples\Ethernet

The example can be found in Circuit #10 and a screen short is shown below.

If your PC has a PHP engine running you could also write a PHP script and wait for HTTP GET command sent by the PLC. The PHP script can then save the data to data file or even directly update to MySQL database. You can design your own message exchange format between you PHP script and the PLC. This is more advanced stuff but can be as powerful as you want them to be.

Did you enable the username/password settings in the "Ethernet & ADC Configuration"? If so it will require you to key in the username and password that you have defined in order to login via the Ethernet.

If you are able to connect via the TLServer and serial port, then you can connect to the PLC and retrieve the Ethernet settings and disable the username/password or add in a correct username/password to protect the connection.

In TBASIC all operators are operating on 32-bit  number.

Any integer numbers are always converted into 32-bit integer before applying the math or comparison operation.

So even if a number is contained in DM[n] the number is first converted ito a 32-bit number and thus any comparison has to be made against a 32-bit number. If DM[n] contains a negative number it will be sign-extended during conversion.