Internet PLC Forum

I am very certain how I destroyed the 1st PLC.  I am using inexpensive 4..20 mA signal generators that can, also, output 0.20 VDC. I screwed up and sent 20 VDC into both ADC inputs.  Not too bright on my part.

I tried to be much more careful with the 2nd NANO-10.  Both ADCs worked with 4-20 mA signals. I then worked on refining my digital signal processing software using ADC[1].  I then added in ADC[2] to my test code snd found that ADC[2] was not working.  I don’t know how I damaged the 2nd PLC, but I did.

I have found a 3rd NANO-10 in my collection of PLC stuff. I will see if it works and add the input protection circuitry.  If I can’t get it working I will order another NANO-10.

Regards,

Gary Dickinson

I am working with a Nano-10 to work with 4-20 mA sensors.

The Nano-10 does not appear to have an analog ground connection.  The best that I can do is connect the free end of the current sense resistor to my common DC bus.

I am concerned about minimizing noise pickup by the ADC circuitry.

Is there a spot on the Nano-10 that I could solder onto as an analog ground?

Gary Dickinson

Getting FileZila to communicate with the TRI PLCs is a little tricky.  FTP is a protocol that dates back to 1971 before TCP/IP or the internet existed. The FTP support built in the the TRI Nano10 PLCs is very limited in what it can support.  You must configure FileZila very carefully to get it to work.

The two big issues is that the FMD PLC can only support a single FTP connection at a time. The FMD PLCs only work with text ASCII text files. The TRI PLCs do not use meaningful time stamps on the files.

OK. Your question talks about the "TLServer". The Nano10 has a builtin Ethernet support and builtin FTP support and does not require the TLServer application to function. If you are actually running TLServer on your PC you will fail.

If your Nano10 and PC are connected via Ethernet to a common network on the same sub net  then you should be good to go.

I have attached a .pdf to this reply that is screen shots of the current version running on a Windows 10 PC and communicating with a FMD series PLC. The Nano10 and the FMD PLCs behave identically when it comes to FTP.

Best of luck,

Gary Dickinson

Lorne,

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[]
next


Gary Dickinson

Pete,

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

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

Lorne,

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