Internet PLC Forum

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:

Ch1Intr
----||-----------------------------------------(Ch1IntrDly)

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.

Ch1IntrDly
----||-----------------------------------------(Ch1IntrDly2)

Ch1Intr
----||-----------------------------------------(Ch1IntrDly)

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

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

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:

https://triplc.com/documents/Fx1616-BA-UserManual.pdf
https://triplc.com/documents/Fx1616-BA_Product_Info_Sheet.pdf

Thanks,

Gary d

Neal,

Good to hear that you have gotten stuff to work. 

I don’t know the answer to your question about connecting two Ethernet devices together with a single cable.  In the old days this required a cross over cable. However in modern times most Ethernet transceivers will work with cables that have the paired signals reversed.  Give it a try.

Another thing you can do is to put all of your devices on RS485.  The HMI will be the master and can access registers and coils in both the PLC and the temp controller.

As an example, I have a client that uses an FMD (integer PLC) with a Weintek HMI. The PLC needed to solve a complex bit of math that was best done in floating point.

The solution was to use DM32[] to hold the data to be processed and to hold the results. 2 PLC RELAYS were used. One to request that the HMI PROCESS the integer data. The second RELAY was set by the HMI after the data was processed and the results had been written back into DM32[].

In your application you could have the HMI poll your Temp controller periodically and update PLC registers with this data.  You could have the HMI program the temperature controller on request of the PLC.  Same approach, PLC data and one or two RELAYs for handshake.

If this craziness is of interest, l can post how to write a periodic HMI macro.

Gary d

Very good work at sorting the RS-485 communications.  This is a very old communication scheme and you have done some old-school trouble shooting.

The issue with the need to bias the RS-485 lines makes perfect sense. I have been lucky in that the external devices that I have worked with all used modern RS-485 Transceivers that didn’t require the biasing circuitry.

Gary d

can,

I don't have an answer to why long messages are not accepted by the target device.

I assume that the target device is not a PLC.  So you don't have much visibility into what the device is "seeing" on it's end of the serial cable.

Since all of your print statements are are all on the same line of TBASIC and the total number of characters is less than the PLC transmit buffer size of 256 then my usual idea about gaps in the data stream probably do not apply.

OK so now I am down to other reasons that things might go south...

BAUD rate might be a problem.  If the target devices firmware is dumb, has a very short buffer or is just badly implemented firmware, then you may be sending characters faster that the target device can handle.  Drop the BAUD rate to something like 300 (about 30 characters per second).  If this fixes the problem then you have learned something about the target device. 

I run 9600 for my Modbus communications because it is fast enough for my applications. It is slow enough to not need termination resistors even with long cables.

If I  suspect the PLC programming is messing up the transmitted string, then i monitor the serial line to see exactly what is being transmitted.

COMM3 is RS485, you will need  a RS485 to USB dongle for your PC.  I use a shareware program named "Tera Term" to monitor the serial port that the USB dongle has been assigned by your PC.  This will allow you to both observe and log the data that is being transmitted from the PLC's COMM 3 port.

If you have one of the "smart" sampling oscilloscope most can decode ASCII serial data.

Good luck,

Gary D

can,

If your application is just to act as a simple store and forward device and does not interpret or validate the received messages, then you just need to check the state of the receive buffer on each scan of the ladder logic and copy any and all received data bytes to the transmit port.

I am assuming that your issue is non-trivial.

The simple answer about communication protocols that require > 256 characters to be transmitted or received is "maybe".

Let's talk about sending long messages:

• There is a 256 byte output buffer for each communication port. Characters are placed in the buffer as the result of OUTCOMM and PRINT statements. Characters are removed from this buffer by low-level PLC firmware.  This firmware moves the data into a second buffer of 16 to 32 characters that are managed by the the UART. The UART is responsible for converting the data into a series of bits and shipping them out as a serial data stream.
• If you your outbound message is greater than 256 characters you will have to divide the message into chunks less than 256 to fit into the output buffer.
• There is no mechanism in TBASIC to determine the state of the output buffer.  The only way to prevent corruption of the buffer is to pace the OUPUTCOM or PRINT statements.  If you communicating at 9600 BAUD each character takes 1.042 ms to transmit. If each of your PRINT statements sends 256 characters you will have to wait at least 267 ms between PRINT statements to prevent corruption of the output buffer.  You are hoping that the output buffer is empty before the next PRINT statement.

Let's talk about receiving long messages:

• There is a 256 byte receive buffer for each communication port. Received characters are placed into the 256 byte buffer by means of low-level PLC firmware.
• The INCOMM(ch) command returns a value of -1 if the receive buffer is empty. I would suggest reading received data with this command and buffer it in DM[].
• It is the responsibility of your TBASIC code to pull characters out of the receive buffer faster than they are received.  Failure to do so will result in corruption of the input buffer. If you are at 9600 BAUD then you must be able to receive 256 characters in 267 ms.
• I would suggest checking for received characters on each scan of the ladder logic and reading all characters from the receive buffer if any are detected. Remember that at 9600 BAUD that characters will arrive every 0.001 seconds. You will have to buffer the received characters using DM[] or EPP (if you have installed the RTC 256K module).

Let's talk about your communication protocol:

• How tolerant is it with gaps in the messages that you will be transmitting?
• If you are sending messages in chunks, then there will be gaps in time when no characters are transmitted. If you protocol has some sort of timeout mechanism, you will have to ensure that the transmit gaps are short enough so that the receiving end does not timeout and long enough that to prevent corruption of the PLC output buffer.
• Modbus RTU expects a message to be sent without gaps between characters.  A gap is interpreted as an end of message. In order to not have a gap in output Modbus RTU frames, I buffer everything, compute the CRC and send the entire frame in one tight loop.  I limit the message size to less than 256 characters to avoid any gaps in the transmission.

Gary D[/list][/list][/list]