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.

Messages - support

Pages: 1 2 [3] 4 5 ... 208
Each time when you make a Modbus TCP connection to the (3rd party) Modbus TCP server you have to wait for the connection to be made before you can run the READMODBUS or WRITEMODBUS command successfully.

Since you have two Modbus TCP server devices and there is only one client port on the FMD PLC, you have to make a connection, check that the connection is successful, the perform the READMODBUS or WRITEMODBUS command, then check STATUS(2) to ensure that you get a good result. Finally close the connection. You then connect to the second device and you must do the same by checking that the connection is made then READ or WRITEMODBUS command, check the communication status, then close the port.

It can be done on the fly reasonably fast especially the the devices are all on a LAN.

Technical support / Re:Jog Moves with Step / Dir
« on: March 12, 2019, 09:55:22 AM »
Gary's suggestion is what we would normally advise users too.

The good news is that since firmware version r70 (on FMD and Nano-10) and on all the Fx series since firware version F90.0 we have implemented stepjog function which is to STEPMOVE with either &H7fffffff or &H80000001 for infinite rotation in positve or negative directions, respectively.

Hopefully this answers to your question. This should have been included in the manual. Will bring this up with the staff who maintain the manuals to include in future editions.

Technical support / Re:NETCMD$
« on: March 02, 2019, 01:46:28 PM »
Unlike serial port connecting via Ethernet is not a one to one. All Ethernet communication are made via virtual connection channel established in a shared medium.

So you must first make a  connection to the server using the PRINT #4 "<CONNECT>.

You have to verify that the connection is successful. After the connection has been established, you can the communicate with the slave using the same NETCMD$ command and yes you can just replace the comm port #2 with comm port #4 and all the commands are identical.

Your program should also monitor the connection and stop the communication if the socket connection has been lost with the server.

Technical support / Re:Reading Mechanical Encoder
« on: March 01, 2019, 08:26:35 AM »
The FMD, Nano-10 and Fx series of PLC can directly read standard quadrature encoder inputs. Each high speed counter only needs two digital inputs (see Chapter 6 on the mappings to the digital inputs).

However, if you are trying to read a specialty encoder using ladder logic it may not be fast enough to process in real time due to the time lag in the I/O scan (about 2ms for FMD and Fx PLC. Much shorter for Nano-10 since there is no expansion I/O) which means that you may miss some rising / falling edge.

You may also try to use the interrupt inputs to handle the specialty encoder.

Technical support / Re:Perplexed by puzzling parentheses pecualiarity
« on: February 21, 2019, 12:16:14 PM »
Thanks Gary for the formula.

To increase precision you can use a fixed point format

F = C*90/5 + 320

The result will be expressed in 0.1 degree F.

E.g. C = 22 degree

F = 22*90/5 + 320 = 716  = 71.6 degree F.

Hi Gary,

It appears that the funny characters all appear in the TBASIC codes that you are showing in your post. Did you copy those directly off a custom function editor or were these exported to an external file and then copied from the external file?

I copied one of the fragment of codes you posted  that was showing funny characters and pasted inside a TL6 custom function. I removed the funny characters and replaced them with TABs,  then copy them back and paste them into this forum post as shown  below:

' Custom function to print 0..99 on serial device #2
' This is the text that will be sent to the serial device:
'   00 01 02 03 04 05 06 07 08 09
'   10 11 12 13 14 15 16 17 18 19
'   20 21 22 23 24 25 26 27 28 29
'   30 31 32 33 34 35 36 37 38 39
'   40 41 42 43 44 45 46 47 48 49
'   50 51 52 53 54 55 56 57 58 59
'   60 61 62 63 64 65 66 67 68 69
'   70 71 72 73 74 75 76 77 78 79
'   80 81 82 83 84 85 86 87 88 89
'   90 91 92 93 94 95 96 97 98 99
print #2 "First Version"      ' Debug Message
for i = 0 to 9         ' outer loop for the 1s digits
   for j = 0 to 9      '   inner loop for the 10s digits
   print  #2 i;j;" ";      '  print each number with 2 digits and a space
   print #2            '  newline at the end of each group of 10 numbers

The funny characters are no longer there.

Thank you for your feedback. Is there a specific forum thread that is showing the funny character that you mentioned? Did you try with a different browser and do all of them show the same funny characters?

We have not made any changes to the underlying PHP code for the forum. In fact we didn't upgrade the PHP because of the concern that it may break the code. But the browsers might have moved on and beginning to "not like" the code executed by the old PHP codes? We are not too sure.

Technical support / Re:PLC hanging
« on: January 08, 2019, 09:52:23 AM »
It may be caused by an actual undefined interrupt that was triggered when the STEPSTOP command was executed. STEPSTOP disables interrupt channel and if this was done in a untimely manner it could result in the CPU chip throwing an undefined interrupt exception because of some internal register conflicts. It doesn't happen most of the time but it is one of those time when "all stars aligned" that the undefined interrupt exception was triggered.

The earlier firmware versions (r76 was released in 2010) did not build in enough software mechanism to protect against the undefined interrupt that could result from untimely disabling of interrupt. We believe the subsequent firmware has mostly fixed such issues.

You can either upgrade the firmware (r76 it is not field upgradable so it will need to be sent back for factory upgrade) or you can define an interrupt custom function using INTRDEF 100, n, 1   where n is the custom function number that is used to trap the Undefined Interrupt. Within this error trap custom function you can save the data you need and then issue a REBOOT command to restart the CPU and recover from the undefined interrupt so that the controller will not stop operating.

Technical support / Re:Watch dog timer.
« on: December 11, 2018, 08:03:53 PM »
Thanks for the valuable input and we certainly would consider experimenting with your suggestions to see if we could incorporate them into future firmware releases. The FxCPU firmware is pretty stable already and we haven't made any major changes in the past 2-3 years. We shall weigh the merit of the suggested changes (how often they will be used) against the additional coding costs (memory space, developing and testing the additional code and mostly making sure that the additional code will not introduce new problems to the existing system).  We will keep you posted.

Technical support / Re:fx2424 output current
« on: December 07, 2018, 08:11:04 AM »
Gary's suggestion is mostly correct - Thanks for the great explanation about the behavior between MOSFET and Bipolar.

What is the peak current draw by your solenoid? What is the longest duration that the solenoid will be energized?

The output 17-24 on the Fx2424 are MOSFET that can handle peak current of 1A but continuous current should be kept < 250mA. They also have short circuit protection so are reasonably robust.

If the solenoid are energized only briefly (a few seconds) and then turned OFF you probably should be able to parallel two or more of the outputs to handle the high current. But if you expect the solenoid to be energized most of the time then a higher current external buffer is recommended. You can construct one quite easily using P-channel MOSFET with the PLC's output driving the gate. (see below image that found on Google)

Technical support / Re:Watch dog timer.
« on: December 07, 2018, 07:46:25 AM »
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.

Technical support / Re:use of the goto @n statement
« on: December 07, 2018, 07:28:13 AM »
We have confirmed that the bug was caused by the conversion of the unsigned byte (0-255) into signed value in Java. This bug was introduced when the original DOS version of TRiLOGI (written in Turbo C) was ported to Java in early 2000, and Java treated "byte" as signed value (Java does not support unsigned anything). So you already know what happened when unsigned value was treated as signed... Anyway this will be fixed in next release of TRiLOGI 6 and 7.

Once again thank you for helping us with the bug report. This is a minor bug that would not affect the PLC program since it wouldn't compile so you get to correct it by using a small n value for the GOTO @n as what you already did.

Technical support / Re:use of the goto @n statement
« on: December 06, 2018, 10:39:32 PM »
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.

Technical support / Re:Watch dog timer.
« on: November 29, 2018, 07:03:46 PM »
If you have enabled WDT but there is no custom functions at all in the program there is no place to run the reset WDT. So again the firmware will automatically reset the WDT at the end of a ladder logic scan since this is considered normal program. If the CPU crash at some unexpected location it is not going to execute the ladder program to the end in order for the WDT to be reset by the ladder logic scanner, and a WDT time-out will occur.

Are you connected to the PLC via the Ethernet? A reboot by WDT time out will leave the Ethernet connection "half-open" and the i-TRiLOGI does not know that the connection is lost until after some repeated time-out. That is why you need to disconnect from the PLC in order to connect again. If i-TRiLOGI is monitoring the PLC via serial port then you should not need to disconnect and reconnect again.

Technical support / Re:Watch dog timer.
« on: November 27, 2018, 09:50:55 PM »
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.

Pages: 1 2 [3] 4 5 ... 208