Internet PLC Forum

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.

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.

Note:
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.

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)
NEXT

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.

I can think of 3 reasonable approaches:

• Use the SetHigh statement to build a 32 bit variable in A:
  A = RELAY[2]
  SETHIGH16 A,RELAY[1]
• 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]:
  DM[1]=RELAY[1]
  DM[2]=RELAY[2]

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]

The following links is a screen capture of an external 4K monitor connected to a 4K screen laptop with a GTX960M graphic card. Connection was via a HDMI cable.

https://www.triplc.com/smf/attachments/20191214/external4Kscreenshot.jpg

The i-TRiLOGI runs properly on either 4K monitors. We have tried different settings and font sizes on i-TRiLOGI and also mouse-over the buttons (see popup tooltip) but the function panels was never messed up like on your screen shot. 

Question - what display scaling did you use on your 4K monitor? We were using 125% and 100% scaling without any issue. Can you try with 100% scaling and see if it works for you?

No it should be 32-bit JRE. I thought you may have installed 64-bit JRE which won't work properly.

For graphic card RTX2060 - unfortunately we don't have such a graphic card handy. If the graphic card driver screws up the display there is very little we can do on the Java source code side to mitigate it since it is not a programming issue but a glitch in the underlying interaction between the O/S, JRE and Java bytecode. Perhaps the glitch can be reported to the graphic card manufacturer to see if they have an updated driver software that will address the issue.

Meanwhile, you may want to keep the editing done on your laptop screen if it works well in the HD mode.
 

Hi Gary,

Thanks for the excellent explanation. We couldn't have done it any better than what you did.

Just add a note to someone new to TBASIC - the variables represented by INPUT[] and OUTPUT[] are stored in internal memory and they are normally only synchronized to the physical I/Os at the end of the ladder logic scan. So it will be a mistake to monitor an input inside a TBASIC loop because these internal memory do not change state:

E.g.
WHILE 1
   IF TESTIO(IN5) EXIT: ENDIF
ENDWHILE

The PLC program will be stuck in the WHILE loop because IN5 will never be turned ON.  You can force the internal I/O to be updated using the REFRESH statement:

WHILE 1
   IF TESTIO(IN5) EXIT: ENDIF
   REFRESH
ENDWHILE

REFRESH statement will update the memory INPUT[] to the states of the associated 16 physical inputs. There is a penalty of I/O scan time being used each time you run the REFRESH statement (about 2ms for a FMD or Fx PLC, shorter for Nano-10) so you want to use it only when necessary.  Letting the ladder logic monitor changes in input and use it to trigger custom functions for TBASIC processing will normally be a lot more efficient than monitoring it inside a WHILE loop.