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 ... 3 4 [5] 6 7 ... 207
Technical support / Re:HST
« on: October 06, 2017, 03:48:13 AM »
If you put HSTIMER 2 on an INIT custom function invoked by 1st.Scan then every time the PLC is reset the high speed timer 1 and 2 will be enabled.

However, the present values of the timers are not saved when power is lost.

If you need to keep the present values of these two timers you could set up a power failure interrupt (see INTRDEF function) and inside the power failure interrupt service routine  you can save the present values of the two timers to FRAM area.

Inside the INIT function you will then load the timer's present value from the FRAM location that holds the previous data. This way the high speed timer can resume its count down after a power failure or reboot.

Technical support / Re:Save as problem 7.12 build 3
« on: October 04, 2017, 12:12:51 PM »
If you want to include period in the file name you should specifically add in the extension ".PC7" at the end of the file name. TL7 does not automatically append the .PC7 extension if the file name entered already include period. This is to allow TL7 to save to file with other extension besides .PC7 (e.g. you can save file as .PC6 extension). So basically the file you have saved to is "PLC 10.3.2017 rev 1" without the .PC7 extension.

In your case you can still see and open the file name if you specify '*.*" in the file name field since that will not use extension filter "*.PC7".

Modbus register are all organized as 16-bit integer.

The PLC can only read these as 16-bit number or can read two adjacent 16-bit number to form a 32-bit integer.

However the FMD PLC does not support floating point so it cannot treat the 32-bit number as single precision floating point number.

Only the Fx1616-BA, Fx2424 or SmartTILE-Fx based PLC can interpret the 32-bit number as single precision floating point number.

The best way to troubleshoot communication problems between two devices is to be able to see the communication going on.

So you should use a USB-RS485 adapter (e.g. U-485) connected to a PC. Connect the RS485 port of the U-485 to the RS485 bus connecting the FMD PLC and the device. Now run a terminal emulation software that can display binary data and trigger the custom function to send Modbus command from the FMD PLC. You should observe the correct Modbus command packet sent from the PLC to the device.

If the PLC has correctly sent the Modbus packet and the slave is of the same communication parameters and correct ID you should see a response packet returned by the slave device.

If there is something wrong with the communication then you may be able to figure out what went wrong.

Technical support / Re:Unlocking a FX Plc
« on: September 20, 2017, 11:00:14 PM »
If you want to prevent hacking from the Internet (since you mentioned router) then you should use i-TRiLOGI "Controller->Ethernet & ADC Configuration" screen to create a password and check the "Use username/password" radio button to "Yes". This password will prevent unauthorized access from the Internet via i-TRiLOGI or the web browser, but will not affect serial device (such as FP4030MR) that has physical connection to the PLC.

The SETPASSWORD keyword is actually a legacy feature in the PLC that is seldom used today. In 1993 when our T100MD and T100MX PLCs were first designed for OEM, the term "Internet" did not even exist (there were networks such as  Bit-net used between universities, but nothing for the public) . Back then the only way to  connect to a remote PLC was to use two telephone lines connected via dial-up modem, one on the PC side and the other on the PLC side. The modems typically ran at 1200, 2400 or up a zippy 9600 bps(!).  Since the modem is connected to a telephone land-line anyone who knows the phone number can dial in and control the PLC using the TRiLOGI software. The SETPASSWORD command was created to prevent unauthorized access by demanding the connecting software presents the unlock password before any further communication is possible.

We still support the SETPASSWORD feature for backward compatibility but it is not really needed today since landline modems can now only be found in the same museum along side the dinosaurs :)

In your sample program "Initialization" you run SETBAUD to COMM1 but COMM2 was commented out. That means COMM2 (RS485) port will still be operating at default 38400,8,1,n

But your "MBRTU" function contains READMB2 12,....    which means you are trying to use COMM2  (RS485) to talk to your device.

I am not sure why there was the  line SETSYSTEM 12,1  in your initialization code. Are you trying to use Modbus TCP to talk to a device that is connected to COMM1 of the PLC using Modbus RTU? That is one purpose of SETSYSTEM 12,1, which is to act as an Modbus TCP to Modbus RTU gateway

Perhaps you want to just define one COMM port at a time for your test to avoid confusion.

Also was there any data received into DM[4], DM[5].....DM[9]?

You can remove the FOR NEXT Loop in the Checkstatus1 function because READMB2 function will run to completion and STATUS(2) will immediately indicate whether the communication was successful so there is no need to put a FOR NEXT loop to test for STATUS(2).

You can remove the checkcom function as it does not serve any purpose and only will slow down the program.

You did not specify what was the problem.

Anyway, as per our previous post if you have some doubt about communicating with a 3rd party Modbus slave, always use a PC based application such as the Modbus Poll software to test your hardware. Once you get a successful communication you would have figured out most of the parameters required for a successful communication, such as the actual binary address, the function and the communication parameters.

For RTU another way to troubleshoot the communication problem is to use a PC to monitor the communication packet exchange between the PLC and the Modbus RTU slave. What you need is a USB to RS485 adapter (e.g. the U-485) and connect to the RS485 bus between the two devices, then download and run a terminal emulation software to monitor the comm. One good and free software is the RealTerm software that can display binary data exchange.

Technical support / Re:TIMER Contact Behavior
« on: September 19, 2017, 09:47:31 AM »
Thanks for helping to document the timer behavior. You are mostly right simply based on your observation! The followings describe exactly what happens during the timer updates:

1. Following reset, the input state for all TIMERs is set to zero to indicate that the TIMERs are inactive.
   The contact associated with each TIMER is set to 0 to indicate that the TIMER has not timed out.
   The timer present value are all set to -1, indicating that the timer is inactive.

2. On the each scan of the ladder logic the evaluates the control input state for each structure during the
   ladder logic scan.  This state is maintained in the data structure associated with the TIMER.

3. If the ladder logic scan determines that the TIMER control input is 0 or false, the contact associated with the
   TIMER is set to 0 or de-asserted and the timer PV is set to -1.

4. If the ladder logic scan detects that the TIMER control input has transitioned to l, then the TIMER is active.
   The TIMER PV is reloaded from SV and the TIMER's contact is set to 0 or FALSE. These changes happen when the
   rung of ladder logic that controls the TIMER is executed.  These changes are visible to all other rungs of ladder
   logic that follows the rung that controls the TIMER.

5. Every 0.01s the timer countdown task is run. If a timer's PV is >= 0 it will be processed either every time the
   timer countdown task is run (for high speed timers with 0.01s time-base) or every 10th time the timer countdown
   task is run (for regular timers with 0.1s time-base). Timer countdown task runs on interrupt and
   is independent of the PLC program scan time so that the timer can count down accurately even if the program
   scan time is > 0.01s.

   At the start of each ladder logic scan, each TIMER that is active at the end of the previous scan may have its PV
   decremented based on either a 0.1 second or 0.01 clock.
, the I/O scan cycle check and if the TIMER's PV is now 0,
   then the contact associated with this TIMER will be set asserted (set TRUE).  Please note that contact
   transitions for 0..1 at the start of the ladder logic scan and NOT at the rung of code that controls the TIMER. THAT"S RIGHT!!

The most important points to take away from this long winded guess on TIMER behavior is that a TIMER's contact is set TRUE (1) at the beginning of the scan and the contact is set FALSE (0) at the ladder logic rung that controls the TIMER is evaluated.   THAT's RIGHT!!

Technical support / Re:How to read 32bit data from Modbus Registers?
« on: September 19, 2017, 05:29:05 AM »
It is unlikely to be a problem with the PLC as the FMD88-10 has no problem working with many third party Modbus RTU slave and Modbus TCP server. You may want to test the communication between the PC (using the Modbus Poll software that was mentioned in this earlier thread) and communicate your Modbus slave controller to observe if there is any particular issues.

Since you are using Modbus TCP your program also must check if the network connection is still valid before executing the WRITEMODBUS command and READMODBUS command. If the connection is lost then the WRITEMODBUS command will fail to run.

Note that the Modbus client has a time out so if the connection is left idle for longer than the time-out settings (see Ethernet & ADC settings in i-TRiLOGI) the connection will close automatically. If the WRITEMODBUS command is executed infrequently then try to increase the time-out so to maintain the connection. Alternatively close the connection when not in use and re-connect only when you need to execute the MODBUS command.

Technical support / Re:How to read 32bit data from Modbus Registers?
« on: September 05, 2017, 11:07:54 AM »
Try using a PC based Modbus software to test the communication with your device and see if the address and data wrtten is acceptable. That gives you better visibility of what's going on between the Modbus client and the Modbus server. Once you can confirm that the address or data is valid you can then use the same function, address and data to send from the PLC to the device.

One such tool is the Modbus Poll software that you can download from:

They have a free evaluation version that will run for a few minutes and then stop. You can restart it again.

Also try using Modbus function 16 (0x10) to execute the WRITEMODBUS command instead of function 06 in case the device does not support function 06 at this particular address.

Technical support / Re:How to read 32bit data from Modbus Registers?
« on: September 04, 2017, 07:06:42 PM »
Did you get a successful connection before you run the WRITEMODBUS command?

Also I think the device is using the Modicon convention to represent the Modbus registers.

Modicon Convention is as follow:

30001 to 39999  - can only be read using Modbus function 04 and the binary address = Modicon address - 30001

So to read anything in the 30001 to 3999 you use SETSYSTEM 4.4 to change to read the input register, then subtract the given address by 30001

E.g. Version number at address 30001

so  READMODBUS should read from binary address = 30001 - 30001 = 0


40001 to 49999 can only be read using Modbus Function 03 and the binary address =( Modicon address - 40001)

So if you want to write to Modicon address 40493 you should be writing to 40493-40001 = 492.

Give that a try and see if it works for you.

[Edit] - For 40001 to 49999 can only be read using Modbus Function 03 (it was wrongly written as 04 initially).

Technical support / Re:How to read 32bit data from Modbus Registers?
« on: August 25, 2017, 06:44:36 AM »
Is the FMD88-10 the master to read 32-bit data from a slave device?

All Modbus registers are accessed in 16-bit only. To access 32-bit data you normally would need to read two adjacent Modbus registers into two DM16[] and access them as a DM32[] variable.

The PLC handles number in Big Endian. If the slave (server) arrange the data in Little Endian you will need to use TBASIC to swap the two adjacent DMs so that the are arranged in  Big Endian.

Technical support / Re:MODBUS/TCP CONNECTION Problem
« on: August 25, 2017, 06:39:43 AM »
You code did not wait for the MBTCPCONNECT to complete the connection before you run the READMODBUS command. The program execute much faster than the time it takes to make connection and that's why the READMODBUS command will not be able to obtain the data.

Please follow the example in your TRiLOGI\TL6\usr\samples\Ethernet\ModbusTCPTest.PC6 or download from the following link:

Are there any other interrupt intensive activities going on at the same time. E.g. High speed counter or pulse measurement?

What is your PLC firmware version? If it is >= r83 you could try upgrade the firmware to the latest where interrupt service routine has been improved to avoid overrun of the interrupt service queue where there are lots of interrupt happening at high speed, as reported by Gary. The improved interrupt service has worked well for Gary and eliminated the issue he mentioned, although his issue is quite different from your report.

We are not aware of any issue with the relay not being set after a STEPMOVE or STEPMOVEABS command.

Does the PLC program use the completion relay to trigger another motion immediately? If so, then the completed flag relay that was set in the previous motion will be cleared once a new motion starts. If the PC software did not read the completion relay quickly enough it may just miss the change of state.

Also in your PC program do you use the WR command to write to a relay bank that also includes the completion flag?  What was the command that your PC send to the PLC to trigger the motion?

Pages: 1 ... 3 4 [5] 6 7 ... 207