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 ... 208
Technical support / Re: RS485 sometimes not working well
« on: June 08, 2020, 02:18:40 PM »
What are the other controllers? Are they third party controller?

Do you know if the actual baud rate of those controllers?  Most controllers that advertise 115200 don't actually communicate at that precise baud rate but a close approximation (up to +/-3% of the target baud rate). So is the Fx PLC.  The closest baud rate that Fx PLC support is  117200 which allows it to communicate well with a PC at precisely 115200 bps. But if the other controllers actual baud rate is lower than 115200 then it is likely that the actual baud rate difference is larger than +/-3 %, which can lead to more errors.

Try to communicate at a lower baud rate if the highest baud rate don't work well.

Technical support / Re: RS485 Baud Rate Between Nano-10 and Fx1616-BA
« on: June 04, 2020, 02:59:34 PM »
As explained in the previous post the Fx PLC and the Nano-10 are clocked at different CPU speed so the actual baud rate is the closest possible baud rate that could be derived from the CPU clock.

On further test we found the closest actual baud rates of the two PLCs to the "target" baud rate are:

target: 115200 bps  (PC serial port baud rate).
Nano10: 111607 bps
Fx PLC: 117188 bps

As you can see their actual baud rates are on two different sides of the target baud rate. On their own each is within the +/- 3% allowable variation from the target baud rate.  Unfortunately the difference between them are larger than the +/- 3% allowable range for successful communication at these higher baud rates.

These are hardware limitation and could not be resolved in firmware.

Anyway, the reason our PLCs support 115200 and 230400 is because these are the baud rates that are supported on standard PC serial port (a PC uses dedicated crystal to generate the full range of baud rate).  So the main purpose is to allow these PLCs to communicate with PCs at higher baud rate if necessary.  But these two PLCs unfortunately are not compatible with each other at these higher baud rates.


Technical support / Re: RS485 Baud Rate Between Nano-10 and Fx1616-BA
« on: June 04, 2020, 01:57:41 PM »
Thank you for your report.

Please note that serial port at 230400 bps has a bit time of 4.36us.   Serial port baud rate are usually derived from CPU clock after feeding through some prescaler and divisor and hence the bit rate is often just an approximation. Since not all devices run at the same CPU clock rate the actual serial port speed would vary slightly from one family of device to another.  Asynchronous serial communication such as UART requires both devices to be within +/- 3% of the agreed BAUD rate. i.e a deviation of  just +/-0.14us in bit period would fail the communication at that speed.

We conducted some tests by setting a Fx PLC and a Nano-10 PLC  RS485 port to 230400 bps.

Individually, both the Fx and the Nano10 PLCs are able to communicate with a PC at 230400 bps without any issue in short wire range. We used an internal version of i-TRiLOGI that we can set to 230400 bps and we can sustain online monitoring with each PLC separately.

However, when we setup the Fx PLC to send hostlink command to the Nano-10 PLC at 230400bps, the Nano-10 does not appear to accept the command as per your experience at 230400.

We then setup two Fx PLCs and we are able to use one Fx PLC as master to send hostlink command to the second Fx PLC as slave and the master Fx PLC is able to sustain good communication with the slave Fx PLC.

We believe that these two different family of our PLCs may be incompatible at highest baud rate such as 230400 or even 115200. This is because the Fx PLC and the Nano-10 CPU are clocked at different speed (Fx PLCs are faster) and the timing variation between them could be large enough to cause problem.

If you wish for higher communication speed you could try with Ethernet communication. The master Fx PLC is able to connect to each Nano-10 as slave one at a time. It is likely to be faster than serial port.

Technical support / Re: FMD88-10 and UL 61131-2 and UL 60730-2-9
« on: April 15, 2020, 12:32:12 PM »
The FMD88-10 is designed and built to comply to applicable sections in the IEC61131-2 standard. As per the IEC61131-2 standard, our PLCs are designed to safely operate within the specified operating temperature, voltage and current ranges and they are built to withstand momentarily over voltage, over current, reverse polarity and environmental contamination up to pollution degree 2 with no safety issues. Various tests are conducted during design and manufacturing to ensure the PLCs operate properly within their stated specifications. However, at the moment the FMD88-10 PLC is not yet externally certified as a UL-listed component. But that  would not prevent its use in most of the UL listed OEM equipment. We have many OEM users who have incorporated the FMD/Fx series PLC in their UL-listed or even FAA certified equipment. The actual technical requirement of the PLC would be dependent on the particular UL standard applicable to the industry in which the OEM equipment is built to operate. You can inquire with your UL rep for any specific technical requirement that the PLC must meet in order to satisfy the applicable UL standard and we would be able to advise you if the FMD88-10 is suitable for the application.

Technical support / Re: Custom function
« on: April 13, 2020, 10:01:37 AM »
This email reply to you was provided to support for this thread:

The best way is to use the STEPMOVEABS and STEPCOUNTABS commands to change and measure position around a fixed point. What you would do is move your motor to a position you would like to call zero and run the STEPHOME command.

From there you can move forward or backward using STEPMOVEABS and return the count from your zero position using STEPCOUNTABS. If you want to define a "home" position as 1000, then you can use define variables to create constant or variable values with names relevant to you (anything allowed by the define table naming conventions), and then use these as parameters for the STEPMOVEABS command.


It will be even more accurate if you can provide position feedback from your stepper driver to the PLC HSC inputs. STEPCOUNTABS will account for the pulses sent out of the PLC outputs, but it can't know about the actual physical movement, which requires encoder feedback from the driver itself.

The only problem is when the PLC loses power and you don't know for sure what the position of the stepper motor is when it powers up. You can always store position and home values in permanent memory, but the motor could have physically moved after power is lost and the PLC obviously can't detect that, so your power up position will be different than expected (the same problem will exist with any additional stephome command to support your request.

To resolve the issue of position loss when the PLC is powered down, you can add limit switches to zero the motor on power up and then use my solution to create fixed or dynamic home positions.

Here is a description of the STEPMOVEABS command, which you can also view online:

STEPMOVEABS ch, position, r 


This new command allows you to move the stepper motor # ch to an absolute position indicated by the position parameter. At the end of the move the relay #r will be turned ON. position can be between -231 to +231 .(i.e. about ± 2 x 109) steps. The absolute position is calculated with respect to the last move from the "HOME" position. (The HOME position is set when the STEPHOME command is executed). The speed and acceleration profile are determined by the STEPSPEED command as in the original command set.

This command automatically computes the number of pulses and direction required to move the stepper motor to the new position with respect to the current location. The current location can be determined at any time by the STEPCOUNTABS( ) function.

Once STEPMOVEABS command is executed, re-execution of this command or the STEPMOVE command will have no effect until the entire motion is completed or aborted by the STEPSTOP command.

See Also



Technical support / Re: Custom function
« on: April 11, 2020, 03:06:09 PM »
Some issues:

STEPMOVE 1, DrillSteps, 9, 9999, 90  - too many parameters

Note that when you run the STEPMOVE1 command it does not block execution of the program. The PLC setup the parameters for the interrupt service routine to handle the stepper motion so if you are testing for a "Drill Complete" flag right after running the STEPMOVE command it will never work since it takes time for the stepper motor to complete the motion.

The Drill complete flag will be turned ON when the move it complete so you can use it to run a function to decide what is the next step to do after the move is completed.

Technical support / Re: permanently latched input
« on: March 28, 2020, 12:19:22 AM »
Did you ever remove the SmartTILE-Fx CPU board from the carrier board previously?

It sounds like the SmartTILE-Fx board may have suffered some damage.

However, the best way is to request for an RMA (email and ship the PLC back to our office for testing. It is likely to be repairable unless there was catastrophic damage to the board.

Please include your company name and contact person name when contacting us. Some explanation of what the PLC underwent would be helpful for diagnosis.

Technical support / Re: FMD1616 - Open Socket TCP as server(slave)
« on: March 19, 2020, 07:40:44 PM »
You can only specify the destination port, not the source port. The source port is assigned by the OS and incremented after every connect disconnect which comply to internet RFC. You can't fix the source port number.

FMD1616 PLC server socket is to service the iTRILOGI client. It can also service HTTP protocol commands sent from a HTTPRequest process. Please refer to Chapter 2.7 of the FMD User Manual for details.

Technical support / Re: FMD1616 - Open Socket TCP as server(slave)
« on: March 17, 2020, 12:21:15 AM »
Yes if the Linux server is listening on a TCP socket the FMD1616 PLC is able to using PRINT #4 "<TCPCONNECT ...>" command to connect to the server port and interact with the server.

Technical support / Re: FMD1616 - Open Socket TCP as server(slave)
« on: March 16, 2020, 03:39:06 PM »
The FMD1616 PLC server socket is always open. So you just need the client to connect to it. iTRiLOGI is a client that can connect to the PLC's server socket.

The TBASIC language does not have built-in support for user initiated UDP client connection to external UDP server. Only TCP client connection is supported.

Technical support / Re: Bit Shift
« on: March 10, 2020, 02:00:10 PM »
Attached is a sample program for using the LSHIFT function for multiple bits.

A parameter X that contains the number of bits is passed to the function fnLShiftXBit which then uses a FOR NEXT loop to shift X bits to the left.

We cascaded two relay channels so that the single bit will shift across both RELAY[1] and RELAY[2] - total 32-bits. You can change the number of channels to 1 if you just want the shift to happen within RELAY[1] and not moving into the higher RELAY[n] channels.

Technical support / Re: ADC not being read
« on: February 29, 2020, 08:33:44 PM »
So does DM[2] and DM[3] return value you expected or do they all return only zero?

Did you connect the voltage to ADC(1) and ADC(2). Note that ADC(1) is on the PIN 8 of the DB15 connector and ADC(2) is on the PIN 7 of the DB15 connector. Please make sure that you have applied analog voltage to the correct PIN on the DB15 connector.

Technical support / Re: ADC not being read
« on: February 28, 2020, 11:58:41 PM »
You need a program inside the PLC that run the ADC(n) function to read the value of ADC channel n.

The PLC does not want to waste CPU cycle to read ADC if it is not required in the program.

You can use a clock pulse such as 0.1s to drive a custom function. Inside the custom function you can write the following:

FOR I = 1 to 8
    DM = ADC(I)

The ADC channel data will be read into DM[1] to DM[8] and their value will also be available on the online monitoring screen.

Technical support / Re: 16 BIT TO 32 BIT
« on: January 24, 2020, 12:10:58 PM »
Do you or anyone else know how to solve the issue of the simulator stopping and causing you to have to close down the software and reboot only for it to work for another 5 to 1o minutes. This only seems to happen on the computer with Windows 10 I never experienced this on my computer with Windows XP

We have been using Windows 10 for a few years already and do not experience simulator stopping issue. Do note that TRiLOGI is written to run on 32-bit Java JRE and does tend to encounter problems when it is running on 64-bit Java.

In the latest iTRiLOGI 6.6 and 7.2 the 32-bit Java JRE is automatically installed and invoked by the TL66.exe and TL32.exe.  If you have older version of TRiLOGI you may want to consider upgrading them which also resolves the problems that could be caused by incompatible JRE.  If the Java update does remove critical files on the 32-bit java then you need to re-run the SetupTL7.exe program to re-install the correct JRE.

Also whenever your PC prompt you to update the (usually 64-bit) JRE, make sure that if you are given an option, do not allow it to "search and destroy" older java on the PC. The 32-bit JRE installed in the TRiLOGI folder will only be used by TRiLOGI and would not affect your other PC program that may need to use the latest 64-bit JRE.

Technical support / Re: 16 BIT TO 32 BIT
« on: January 24, 2020, 12:01:57 PM »

I can think of 3 reasonable approaches:
  • Use the SetHigh statement to build a 32 bit variable in A:
    A = RELAY[2]
  • Build a 32 bit variable in A
    A=RELAY[1] * &h10000            ‘ shift left 16 bits
    A=A | (RELAY[2] | &h0000ffff)   ‘ OR in least significant 16 bits
  • Take advantage of the fact that the DM memory can be accessed as both 16 bit and 32 bit values.  In "C-like" programming languages this is an example of a "union" data structure. This code will build a 32-bit value in DM32[1]:
Try them in the simulator. Pay close attention to where the bits from RELAY[1] and RELAY[2] end up in the 32 bit value.  Set the most significant bit of each group of relays and verify that you get the correct pattern in the 32-bit variable.

Gary Dickinson

Great answers to the question that Lorne posted, Gary!

The 3rd approach is very efficient but just need to remember that when DM32[1] is formed by two adjacent 16-bit DM[1] and DM[2], the upper 16-bit is contained in DM[1] and lower 16-bit is contained in DM[2] (known as the Big Endian representation).  So in order for the relay #1 to 32 to form a 32-bit number the correct assignment is as follow:

DM[2] = RELAY[1]  ' the lower 16-bit
DM[1] = RELAY[2]  ' the upper 16-bit
A = DM32[1]

Pages: [1] 2 3 ... 208