好像没有专门的指令，是不是MOVE指令直接会判断，如果是长整型MOVE到整型，它自动取其中的高16位？

N侠：INT类型的取值范围是-32768～+32767，你附图中的65436是无符号数，转成有符号数，正好就是负整数-100。

我也不知道上面在纠结啥
1，如果数值在整数范围内，那么
L dint
t int
两句话就完事了，纠结什么？
2，如果数值不在整数范围内，那么转换根本无从谈起了，又纠结什么？

先旗帜鲜明的表明态度，支持冬日和zane。


要讨论DI to I的严谨，就必须充分考虑这个数据流的前世今生。
就是产生这个DI的过程中有没有可能产生长于16位的数据，而转换成I以后对于长于16位的数据又是怎么处理的。

从前世来说，如果这个数值无限大，你为啥还要妄图做一次转换呢？啥目的？老老实实在整个数据流中一直使用DI不就挺好吗？比如要把流量累计值送到WINCC，那也就是建立一个DINT的tag而已。

从后世来说，如果你得到了长于16位的数据，现在产生溢出了，你是给送出0呢还是送出高位部分呢，还是送32767呢？依我看，你给送出啥值，都达不到绝对严谨。
别说你还有error状态字，这个状态字给谁看？ 别忘了，你这是PLC，别指望你还能和WINXP一样有个溢出蓝屏的机会！

n次可以把你对error的处理方式再拿出来探讨一下。别说你产生了就不管了啊！

小釉担心的负数时的处理问题，说明你是对数据的结构相当不清楚。
对于一个16位以内的负值，如果它是放在32位里面的，那么整个高位字里面填充的都是1，所以每一位都是符号位！
就比如-1是 1111 1111 1111 1111 1111 1111 1111 1111 。你即便去掉前面的16位的1,最后得到的还是-1 。
就是说，你担心的M102.7的符号位的地方，原本存放的就是1。
这一点，用WIN7里面的计算器，打到程序员模式，可以看的很清楚。
计算机科学的科学家们，显然比你更早的想到了这一点！

支持一下万版
这里对于万版说的关于负数处理的问题，给点理论依据。

在CPU内所有的整型数都是以补码形式存放的，补码的最高位是符号位。
根据补码的符号延展原则，将一个特定位数补码系统的数字要以较多位数表示时（比如8bit到16bit或者16bit到32bit），所有增加的高比特都要填入原数字的符号位。
所以在数据截取时，只要数值没有超过截取后能表示的范围，那么截取后的最高位仍旧与原值的符号位相同。