Internet PLC Forum

Thank you for your suggestions.

If you are using the FMD PLCs, or developing a SmartTILE-Fx based custom PLC you could use the I2C interface (require the I2C-FRTC module for FMD) to interface with other electronic components that support the I2C interface. I2C interface is a much more popular, faster and more robust communication interface than 1-wire.

Network routers have a different design purpose in that it is their job to look out for new connection and to assign IP address.

The PLC fimware initializes the Ethernet parameters during startup and most often the PLC is assigned a fixed IP address during the initialization so that will be the parameter it uses. If the fixed IP address has changed then it require a reboot in order to re-initialize the Ethernet port.

The PLC firmware does not want to spend precious CPU time to periodically check to see if it has if the IP address has changed in order to re-initialize the Ethernet port.

In many applications the PLC may not even be connecting the Ethernet port to the network, hence it is by design that the PLC only check for DHCP IP address (if IP address is set to 0.0.0.0 for Fx based PLC only) during boot up and if it doesn't find an address it assume that there is no network connection or no DHCP server and thus would ignore the Ethernet port.

Gentlemen,

Thank you very much for expressing your opinions as well as kind words about TRi Tech support!

We hear your grievances about the documentation and we will think hard about how to improve them.

I guess a lot of information is sprinkled across TRiLOGI Programmer's Reference, TRiLOGI on-line Help Files and respective PLC User Manuals. So sometimes, the information may not be available if you refer to only one manual.

One solution may be to replicate some of these information to the other manuals. However, many of our PLC User Manuals already run into more than 200 pages, and we are quite reluctant to add more pages, rendering our documentation unwieldy to new users. Also, many users probably don't use all the capabilities our PLCs possess, so the current documentation tries to cover what we think many users will need for common control applications. For users who require more information on topics that involve more in depth knowledge of the PLC capabilities, we are always ready to help with email and tech support on the forum.

Instead of creating one PDF document with hundreds of pages, we probably need to move our documentation online to enable information to become searchable.  We hope to spare the resources to make that transition in the not too distant future.

Thanks again for your feedback. They are always welcome!

If the user does not need to view the ladder logic, then all you need to do is to make a copy of your .PC6/PC7 file and then delete the entire program but keep all the I/O table and #Define table intact.

Your technician will still be able to go online monitoring to view the I/O status and View Variable screens to view all the data on the PLC.

You can set a create a user password on the TLServer with level 3 access (User level) and this user will not be able to change any variables inside the PLC nor reprogram the PLC.

Two possibilities:

1) Your tablet may already come with (or you can buy one easily for Windows based tablet) an Ethernet connector (via USB or USB-C) and all you need to do is to assign your tablet's Ethernet port with a static IP address as well as a static IP address on the PLC (both should be on the same subnet. E.g. PLC=192.168.1.5, tablet=192.168.1.10). Now it is essentially plug and play using a standard network CAT5 cable with RJ45 plugs on both ends. You can either run i-TRILOGI to program the PLC, or run a browser webpage with content loaded from the PLC's web pages that you have preloaded into the PLC.  You can of course always write a Visual C, Visual Basic, or Java program to create a custom software interface for your PLC and communicate with it via the Ethernet port. That software will run on your tablet directly.

2) Since you have a Windows tablet you can easily connect a USB-RS232 or USB-RS485 (U-485 http://www.triplc.com/u485.htm) to the PLC's RS232 or RS485 port. That way you can run TLServer and use i-TRiLOGI to program the PLC. You may not be able to run browser webpage from the PLC, unless the webpages are loaded into the TLServer web file space.  

If you adopt solution 2), then most likely you want to write a custom GUI in C, C# etc to communicate with the PLC via the serial port. Your program of course need a way to either recognize the COM port number or let user select the COM port from drop down menu and memorize it. Thereafter it is more or less plug and play as well.

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".

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.

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.