Internet PLC Forum

Depending on the complexity of the Sanyo protocol it may vary from very easy to complex to program to handle its protocol. If the protocol is ASII based and only need no error check or only need simple error check such as checksum, you can very easily handle it using the NETCMD$ command.

You can take example from our website that demonstrate interfacing the T100MD+ PLC to the I-7000 analog module. The I-7000 has its own very simple ASCII protocol and we used the NETCMD$ to efficiently read or write to the I-7000 modules.

See the following link for details:

http://www.tri-plc.com/i7000.htm
http://www.tri-plc.com/trilogi/I-7000.zip

You can use two 10K resistors in series to divde the 0-10V input to 0-5V so that the ADC can read it. The ADC input are pretty fast response (less than 0.1ms). However, the PLC is really not designed to handle very high speed PID loop like in servo control.  

PLC scan time is about 7 microsecond per word of ladder logic. TBASIC varies from 0.1ms to several ms depending on complexity of the function. It is not very meaningful to talk about "Scan Time" of TBASIC since you don't usually execute the TBASIC at every ladder scan. Instead you execute a custom function once when an event ocurrl or you could use a clock pulse to periodically execute a custom function written in TBASIC.

The smallest deterministic sampling time is using the 0.01s clock pulse, which means about 100 samples per second.

If you run the PLC's serial port at 1200 bps or slower, then the PLC will output data at same or slower speed than the radio can handle. If you then tie the RTS and CTS together (on the radio) you might be able to get it to work.

Anyway, we don't have experience in such application. The above is just a suggesion/guess only.

SETBAUD 1,3 will set COMM1 to 9600, 8 data bit, 1 stop bit and NO parity. But if you define the bar code scanner for even parity then you need to use a different number for SETBAUD 1,n

I assume you have used a clock pulse to periodically execute the Fn #2?

Anyway, you should test whether you have received any input from the PLC by:

  A$ = INPUT$(1)
  IF LEN (A$) = 0 RETURN: ENDIF   ' nothing received.
  SETLCD 1,1, A$+"     "     ' To display captured string.
  A = VAL (A$)
  If A > 0:  B = A:  ENDIF
 
This should work better.

Have you actually tried the sensor interfacing with the analog input instead of using a simulator? Depending on the quality of the PLC power supply as well as sensor power supply, the presense of electrical noise etc you can get different result. So far many users seems satisfied with the slight flickering of the reading.

For water level measurement, since the reading does not change rapidly, you could take a moving average of the signal that you read in. That can be easily accomplished using the math capability of TBASIC.  You can take a moving average of 3 or 5 samples as your final result.

For absolute stability the RS485 based I-7017 will give you excellent result since it is a 16-bit unit with its own isolated power supply. Considering that it gives you 8 channels of 16-bit analog inputs the price is not too expensive.


If you want absolute stability in the reading

Thank you for the update. Yes, it is possible to use a look up table to solve the trig function but provided it is only limited to a small range of values.

What do you mean by "bongs out"? Do you mean you can't load the program into the PLC?

To log the time into DM[n], you just have to assign it:

DM[N] = TIME[1]      ' log hour
DM[N+1] = TIME[2]  ' log minute
DM[N+2] = TIME[3]  ' log second
DM[N+3] = DATE[2]  ' Log Month
DM[N+4] = DATE[3]  ' Log Day

N = N+5

If this use up too much memory you could compress the data into one variable such as:

DM[N+3] = DATE[2]*100+DATE[3]   ' represent as 101 to 1231

In the TRiLOGI version 5.2 we have just released, we have included support for compilation of complex logical expression as per your example.

All licensed TRiLOGI users can obtain free upgrade by following the "upgrade.htm" document in their CD ROM.