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 - garysdickinson

Pages: [1] 2 3 ... 34
Technical support / Re: Reading a string using MODBUS RTU
« on: February 25, 2023, 05:04:16 PM »

I pass strings back and forth between Weintek HMIs and TRI PLCs.  Weintek uses arrays of integers to store strings and packs 2 8-bit characters in each 16 bit value. 

This is the code that I use to convert a PLC string variable into an array of registers that can be accessed via Modbus. The HMI reads/writes 16 sequential registers in the PLC to read/write string data. I picked an array size of 16 16-bit integers. This will support strings up to 32 characters.

' Copy Installation Name String from a$ to DM[] so that it can be accessed by the
'   Weintek HMI as an array of 16-bit Modbus registers
n = InstallationName    ' starting word in DM[] to build the data for the HMI

' SizeInWords is defined as 16.  16 sequential DM[] locations.
for i = 1 to SizeInWords step 2

    ' Two 8-bit ASCII characters are packed into each 16-bit DM value
    ' The Weintek HMI expects strings to be packed into sequential 16-bit words.
    ' The first character in a string is in the LSB of the first word
    '   The second character will be in the MSB of the frist word.
    ' The rest of the bytes are filled with 0x00. This keeps the HMI string object
    '   sane.
    ' Please note that asc() is spec'd to return 0x00 when index is beyond
    '   the end of the string, A$.  It seems to do this in test. This
    '   usage ensures that the entire DM[] array is 0 filled beyond the end
    '   of the string characters.
    DM[n] = asc(A$,i+1) * 256
    DM[n] = DM[n] + asc(A$,i)
    n = n + 1           ' next word in DM[]

Gary Dickinson

Technical support / Re: Input[1] to Input[5] Operation
« on: January 06, 2023, 01:25:10 PM »
Your attempt to use INPUTs as general purpose data storage has a small problem. When the PLC ladder logic is running it will overwrite all of the INPUT values during each scan of ladder logic. You are using INPUTs that your PLC does not physically have but the ladder logic code does not know how many INPUTs your PLC actually has (or are actually being used) so it scans  the maximum number of INPUTs that ladder logic can handle.  This number is way more that 16. This is why your are seeing your "special" INPUTs getting cleared to 0.

I suggest that you store data in either DM[] or RELAYs. If you store your DATA in RELAYs you can make it visible on the first page of the simulator / on-line monitor.

If you insist on using INPUTs for data storage you may need to use the SetSystem 16,n statement on the the first scan of your PLC program. The SetSystem 16,n sets the number of I/O pins that will be accessed.  The "n" argument affects the number of I/Os to access. When n=1 the I/0 pins 1-16 will be scanned. When n=2 then pins 1-32 will be scanned.

SetSystem 16,n is intended to help speedup the execution of ladder logic by restricting the number of I/Os that must be processed on each pass thru the ladder logic.

I use SetSystem 16,n for it's intended purpose to speed up the ladder logic execution. It works for this purpose You will need to test and verify if SetSystem 16,1 will solve the problem that you have created. 

Gary Dickinson

Technical support / Re: goto command
« on: December 21, 2022, 10:46:51 AM »

it sounds like you are working on a fairly complex problem.

As you have figured out the TBASIC language does not have any sort of computed GOTO or computed CALL functionality.  So your choices are to either make the computed CALL using a CF or to do it in ladder logic.

I am guessing that your code is using the variable SeqNo to make decisions.  Most of my  non-trivial  PLC  programs work in this manner. 

The PLCs allow you to use COUNTERs 1..8 as "sequencers". The Present Value of these Sequencer/Counters can be tested in ladder logic and the Preset Values can be changed in ladder logic.  When used as Sequencers you are limited to the values of 0..31.

    I use this mechanism for many reasons:
    • Ladder logic is faster than TBASIC in making these decisions
    • The SeqNo is visible for debug both in simulation and on-line monitoring.
    • The SeqNo can be changed during debug to force code to run. for debug.
    • it provides a method to support multiple threads of operation. Poor-man's multitasking.

This approach scares most PLC programmers because it sounds too complex.

If you are interested, I have posted many examples of this sort of approach.  I’d be happy explain how it works.

Gary d

Technical support / Re: goto command
« on: December 20, 2022, 03:39:28 PM »
I have been writing code for the TRI PLCs for nearly 20 years and have not found a use for the GOTO statement.

I would use the following coding structure for your code:

if SeqNo = 1
    ' code for SeqNo 1
elif SeqNo = 2
    ' code for SeqNo 2
elif SeqNo = 3
    ' code for SeqNo 3
elif SeqNo = 10
    ' code for SeqNo 10
    ' code if the SeqNo is not not 1,2,3, or 10 ...

I think that this approach is easier to read and maintain.  Note that "elif" is identical to "elseif" keyword. I just like the shorter version.


Gary Dickinson

A long time back I worked with the pre-production Wx100 product using any of a number of versions i-TRiLOGI that were test builds.

I got an email from a Wx100 user and he was having problems with compiling a Wx100 program that I wrote.

The affected file is named "Wx100 Simple Menu V1_12.PC7.

The problem is that this demo code was written with an early version of i-TRiLOGI when the "Comment" field was added to the #define mechanism.  The current tool set V7.5 Build 14 uses a different field separator in the .PC7 file than was used by the early version that I wrote the code with...

The early version used commas as field separators in the PC7 file. Sort of like this:  #,Defined Name,Value,Comment
The current tool set uses commas and an ASCII <RS> (record separator). Looks like this: #,Defined Name,Value<RS>Comment

The problem is that my "old" code when compiled with current tools doesn't recognize the "," before the Comment field so the Value field ends up with the correct "Value" a comma and then the Comment text.  The Comment field is always empty.

I was able to fix the problem for the user, by exporting the #Define Table to a text file and replacing the first "," character by an ASCII TAB character and then importing the edited #Define table back into the PC7 program.  The edited #define table now works perfectly and if I peek into the PC7 file I see the <RS> character in the correct spot.

I have attached the corrected .PC7 file.  It is now named "Wx100 Simple Menu V1_13.PC7.  The only changes from the V1_12 file is the corrected #define and I added a comment for the V1.13 version to give a hint as to why it was changed.

I think that the V1.12 version may appear in in the Wx_Specifics directory and in a Zipped file named "Wx100 Simple Menu.  Is this something that you can fix in a future release?

Best regards,

Gary Dickinson

There isn't a Special Clock Pulse bit with a period of 2 seconds.

But there is a 1 second period clock named "Clk:1.0s.

You can use a COUNTER to generate a 2 second clock from Clk:1.0s

The trick is to make the COUTNER count up with the use of special function coil, [UpCntr].

A COUNTER with a set value of 1 will count 0,1,0,1... as an up-counter. The contact for the COUTNER will be active on the "0" count time period.

I have attached a screen shot of of the ladder logic to get this to happen.

Good luck,
Gary Dickinson

Technical support / Re: PLC INPUT Interrupt Behavior
« on: November 07, 2022, 01:34:35 PM »

I think your approach is reasonable. 

The feedback that I got from TRI is that the behaviors vary by PLC family. 

1. The Wx100 is based on a very different processor and the state of the physical INPUTs may continued to be visible to ladder logic while being used as an interrupt source. This is not the case with Fx based PLCs or the older FMD based PLCs.

2. There is some sort of debounce logic on INPUTs to filter out bounces that show up with mechanical contacts.  This mechanism is turned off for those INPUTs that are being used as INPUTs on some PLC  families.  The debounce mechanism is be based on ladder logic scan boundaries and may require more than a single scan to get settled.

The bottom line is that it can take one or more full scans of the ladder logic on most PLC families from when an INPUT interrupt is disabled until that INPUT's true state is visible to ladder logic.

Thanks for helping me think through this stuff.

Gary d

Technical support / Re: PLC INPUT Interrupt Behavior
« on: October 09, 2022, 05:41:22 PM »
I am using the EZWire-1616.

I am using the edge triggered interrupts to terminate a stepper motion on the edge of a limit switch.  I am running the stepper at a very low step rate with no acceleration.  This way the StepStop command will stop the motion as close to the edge event as possible w/o the stepper losing position.

If I do this without using the interrupt system the the stepper can be 50 steps past the edge event as I am limited by the ladder logic scan rate.  Without using interrupts, I have to issue  a one-step motion command to detect the edge event.  These steps are limited by the ladder logic scan rate.  I can get 20..50 pps out of ladder logic.  My stepper hardware can run at 1000 pps and be stopped with StepStop without losing position.  ISR edge detection saves about 8 sections for each stepper based positioner.

If I had 4 additional INPUTS, I could wire 2 PLC inputs in parallel for each limit switch input.  This would get me both ISR and ladder logic visibility to the limit switches.  I will still have to disable the ISRs either by disabling them or substituting a non functional CF for those times when I don’t want the stepper system to be stopped on edge events on the limit switches.

    What how I think that the PLC handles INPUTs and INPUT interrupts:
    • Physical INPUT states are scanned and registered once per scan of the ladder logic. If an INPUT is acting as an interrupt source it’s valve when viewed by ladder logic is always 0, independent of the voltage on the INPUT pin.
    • INPUT interrupts are handled synchronously to the ladder logic scans.  I believe that these are handled directly by the PLC’s CPU. My ISR sets a RELAY to indicate that the edge condition was detected. My ISR, also turns off the INTERRUPT system for the the INPUT before exiting.
    • Ladder logic contacts, INPUTS included, can be differentiated or edge sensitive.  To detect an edge requires 2 successive scans of the ladder logic.
    • I suspect that it takes 2 full ladder scans to get the INPUT state correct after an INPUT interrupt is turned off. But because of the asynchronous behavior of the ISR, it may take a 3rd scan of the ladder logic to get the INPUT working.  My test code counts the number of scans from when a rising edge ISR runs until ladder logic detects the the INPUT is non-zero.  This code sees 2 full scans for about 9 out of 10 tests and 3 scans about 1 out of 10.

    I don’t think that I am observing contact or switch bounce.  I disable the ISR in the ISR routine. I would like to believe that your system level code would disable the CPU ISR before the PLC ISR code exits. Even if the ISR executed 2x, the PLC code will see only a single event from the ISRs.

    I believe that waiting 3 scan times following the ISR detected edge event will allow the PLC INPUT logic to return to "normal" (digital filtering is working), differentiated INPUTs working, …

    As you know, I am just guessing how the PLC operates. I am just picking your brains to see if I am missing something.  I appreciate anything that you can think of.


    Gary Dickinson

Technical support / Re: PLC INPUT Interrupt Behavior
« on: October 06, 2022, 09:42:05 PM »
I wrote some test code to see if I could figure out how long it takes from the time that an active INPUT ISR is turned off via the IntrOff statement to when the state of the physical INPUT can been "seen" by ladder logic.

The amount of time is 2 to 3 scans of the ladder logic. In most cases it takes 2 scans.

I have attached a image of the ladder logic and the complete program for the test to this reply.

The CF, Ch1FndLowSw sets up the interrupt for the INPUT[1] and issues a StepMove command.  The RELAY, GO, will invoke the CF.

The ISR CF, Ch1LmtSLo_Int, will be triggered when the INPUT[1], Ch1LmtSwLo goes active. The ISR is configured to respond to a rising edge event.  The ISR does two important things:
1. Turns off the ISR
2. Sets the RELAY, Ch1Intr to indicate that the interrupt has been serviced.

The CF, IncScanCount increments the TBASIC variable A on each scan of the ladder logic that the CH1Intr RELAY is active.

The PLC code is very simple.  Just complicated enough to answer some of my questions.

Best regards,

Gary Dickinson

Technical support / PLC INPUT Interrupt Behavior
« on: October 05, 2022, 03:12:18 PM »
I have been working on using the INPUT interrupts that are tied to end limit switches for a stepper based motion system.  I have gotten them to work, but am a little confused about the timing.

This is the code for one of the ISRs:

' Ch1LoLmtISR - Interrupt handler for Ch1LmtSwLo
' This code aborts the CH1_Y stepper system when the interrupt condition is met
StepStop CH1_Y          ' Abort Stepper Motion
IntrOff Ch1LmtSwLo_Int  ' Disable interrupts for this Input
SetIO Ch1Intr           ' Set ISR event RELAY

I am aware that while an ISR is active, following the execution of IntrDef, that the INPUT pin status is NOT latched at the end of the ladder logic scan. When the ISR for an input is disabled, the INPUT status is "visible" to ladder logic.  So my "initial fix" was to re-sych the Ch1Intr RELAY at the end of the ladder logic to control a 2nd RELAY, Ch1IntrDly, with something that looks like this:


My assumption is that if the ISR set CH1Intr then waiting one scan time the delayed version of CH1IntrDLY in ladder logic, that the physical INPUT would be visible to the ladder logic.

Sometimes this works and sometimes it does not.  So I added more logic to delay the CH1Intr by a 2nd scan and this worked a bit better, but sometimes failed.



My "ultimate" fix was to make Ch1IntrDly a TIMER and not a RELAY. This will result in multiple scan times before the TIMER goes off.  Now everything is visible to the ladder logic.

Do you have any suggestions on a better approach to "know" when the INPUTs are working after turning off an INPUT interrupt?

Is there some other timing issue that I am missing?

Does the SetStop take a lot of time to execute? If so should I have rearranged the order of the lines of code in the ISR?
Does the IntrOFF statement take effect immediately, or is it delayed to some point in time that is tied to the ladder logic scanner?

Beat regards,

Gary Dickinson

Technical support / Re: Small quibble on Version 7.5 Build 14
« on: September 09, 2022, 10:16:21 AM »
I have another small quibble about the output from the Print Control Panel.

It has to do with the printing ladder logic that uses labels for contacts that are greater than 8 characters in length.  The issue is that the labels simply run together and are difficult to read.

I have attached a couple of screen shots, one showing what the i-TRiLOGI editor page looks like and the other the printout.

I couldn't find a way to decrease the size of the text used for the label or to increase the spacing between contacts in the ladder logic rung.

Is there something that I am missing?

Gary D

Technical support / Re: EZWire1616 Stepper controller OUTPUTs
« on: September 08, 2022, 02:26:10 PM »
Thanks the direct links to the documentation works on both my desktop PC and iPad.

The version of the website that is served to my iPad is the culprit. The links to some of the reference documents are broken.

One other documentation question. There is an on-line view of the TBASIC programming manual that can be reached from the I-TRiLOGI app.  Is there a version of this that I can download as a PDF.

Gary d

Technical support / Small quibble on Version 7.5 Build 14
« on: September 08, 2022, 02:12:25 PM »
The Print Dialog box gets overwritten with parts of the displayed .pc7 file after pressing on the "Print" button.

See attachment

Gary D

Technical support / Re: EZWire1616 Stepper controller OUTPUTs
« on: September 08, 2022, 01:04:45 PM »
Thanks for the quick feedback.  I was using "32" as the channel ID.  The code was originally written in 2015 and run on a Fx1616-BA.

The "32" ID is documented only in the Fx1616-BA User Manual.  This manual is not available for download from your website.  These inks return 404 errors:


Gary d

Technical support / EZWire1616 Stepper controller OUTPUTs
« on: September 07, 2022, 08:32:14 PM »
I am working with the EZWire1616 and have run into some questions with the stepper control mechanism.

I am using CH1 and CH2 to drive external stepper drivers using
PULSE and DIRECTION signals.

The user manual that I can find is Rev 1.0 dated 3/17/2016.  It shows support for 3 steppers with the control signals on OUTPUTS 5 and 6 for CH1. OUTPUTS 9 and 10 for CH2 and 13 and 14 for CH3

The issue is that the CH2 OUTPUTS appear to be actually using 7 and 8 and NOT 9 and 10.

Other documentation on the website says that this PLC only supports 2 steppers and not 3.


What is the correct wiring for CH2?
Is there support for CH3 if I need it?
Is the more accurate documentation available for this PLC?

Gary Dickinson

Pages: [1] 2 3 ... 34