Small behavioral issue with CHR$(n) handling in Simulator

[garysdickinson]

The simulator's handling of CHR$(n) does not match the PLC's behavior.

The simulator accepts 16-bit values for n and can create strings that appear to be an array of 16-bit values.

As an example:

A$ = CHR$(&H4548)

Creates a string that is 1 character in length and this only character has a value of &H4548 when run with the simulator.

When run on a PLC this same code creates a string that is 1 character in length and this character has a value of &H48.

I vote that the PLC's handling is correct.

I suspect that the Java library that you are using supports Unicode in some general way (localization) and that the java code that is close to CHR$() will accept 16-bit Unicode values.

I think that you should mask off and only use the least significant 8 bits of the "n" argument to CHR$(n).  This would make the simulator behavior match the PLC.

I don't care that the simulator implements strings as arrays of 16-bit integers rather than 8-bit integers as the PLC does.  This difference is not important and only shows up because of the implementation of CHR$(n) is flawed.

Gary D*ckinson

[support]

Thanks Gary. Yes, the iTRiLOGI 6 and above supports Unicode and simulator does make use of the available functions on Java. The PLC on the other hand supports only 8-bit ASCII. So as you have suggested we should mask the upper 8-bit of n when simulating the CHR$(n) function so that the simulator would behave the same way as the actual PLC. We would put that in the next release of i-TRiLOGI.

Also thanks for your help in supporting several questions posted by our users in the last couple of days. You have given great replies that we could not have done any better!
 

[garysdickinson]

Thanks.  I like algorithm questions.

I was surprised that my sample code for jbryant87 resulted in unintentional Unicode characters.  So I offered him a second version that forced the argument, n, in CHR$(n) to be in the range of 0..255 (8-bit).  This fixed his problem but bothered me as to why I needed to do this.

I came up with 2 competing theories:

• You guys had secretly added UTF-8 support to TBASIC.  Modified CHR$(n) to accept 16-bit arguments and convert them to multiple UTF-8 bytes.  Modified ASC(A$,i) and MID$ to recognize UTF-8 encoded characters and reconstruct the 16-bit values.  And, were too modest to mention all of these improvements.
• The simulator was handling strings differently then real hardware.

I was getting so excited about the first theory and ignored the fact that the 2nd theory was much more plausible.

Gary D.