Peter Nachtwey
Member
Before I start slamming the IEC specification I want to show the program that 'wound up my integrator'. I wanted to write a quick and dirty random number generator. I found this algorithm. This should be easy.
http://www.codeproject.com/KB/recipes/SimpleRNG.aspx
This looks like java code to me.
I wanted something 'lean and mean' because it is to be used on a motion controller for simulating varying readings etc.
The code translated into two steps
The code works well and runs in 7.2 microseconds but look at all the type conversions!!! I spent as much time converting data types and swearing at the need for this bs as doing useful work. This is nuts. Does the ST code look easier than the Java code? I think Rockwell has the right idea and that conversions should be automatic.
I can't believe that people really want to do all the type conversions when they aren't necessary. No code is generated for the DWORD_TO_DINT or DINT_TO_DWORD or DWORD_TO_DINT so what is the point. However, one opcode is generated for the REAL conversions. Also, they could have used a shorter way of saying DINT_TO_DWORD. How about copying from others instead of making up your own crappy specifications just to be different? Why not do it like in C or java where DINT_TO_DWORD(number) is simply (DWORD)number.
Comments. I like comments. I like C or java comments.
I want to say
I=I+1 // increment I
instead of
I:=I+1 (* increment I *)
If is much easier to hit the same key twice than to (* *).
This is nuts. I don't see how (* *) improves on the tried and true //.
You can see I much prefer using = as an assignment and == as an equality check. I use assignments much more often than I use equality checks.
I have already specified that // will be allowed on our product. I must have // for line comments.
Hex numbers. What is wrong with 0xFFFF?. Again IEC had to make up some thing different. We already allow 0xFFFF as well as 16#FFFF on our product.
Standards limit creativity and searches for better ways of doing things especially when the standards are so flawed and yet so many think IEC is the only way to go.
Is there anybody here that seriously thinks the IEC specification is only way to go? I would prefer a C# or Java or even C++ with the pointers and the need for dynamic memory allocation.
I just wanted to stir thing up and by slamming the the IEC standard and the lemmings. We feel pressure to conform with the IEC specification but I don't think it is the right thing to do because it is flawed. I can provide examples if required. This lemming sees the cliff and feels like he is being pushed along by all the other lemmings. I also wanted point out there is a good way to generate pseudo random numbers is very quick and random enough.
http://www.codeproject.com/KB/recipes/SimpleRNG.aspx
Code:
private static uint GetUint()
{
m_z = 36969 * (m_z & 65535) + (m_z >> 16);
m_w = 18000 * (m_w & 65535) + (m_w >> 16);
return (m_z << 16) + m_w;
}
and
public static double GetUniform()
{
// 0 <= u <= 2^32
uint u = GetUint();
// The magic number below is 1/(2^32 + 2).
// The result is strictly between 0 and 1.
return (u + 1) * 2.328306435454494e-10;
}I wanted something 'lean and mean' because it is to be used on a motion controller for simulating varying readings etc.
The code translated into two steps
Code:
(* Step 0 Initialize once using timers and clocks *)
(* %MD20.2 is a register that the last scan time *)
m_z:=DINT_TO_DWORD(REAL_TO_DINT(%MD20.2*1000000000.0));
m_w:=DINT_TO_DWORD(_SysTicks);
(* Step 1 Run this when a new random number is required *)
m_z:=DINT_TO_DWORD(36969*DWORD_TO_DINT(m_z AND 16#FFFF)+DWORD_TO_DINT(SHR(m_z,16)));
m_w:=DINT_TO_DWORD(18000*DWORD_TO_DINT(m_w AND 16#FFFF)+DWORD_TO_DINT(SHR(m_w,16)));
u := DWORD_TO_DINT( SHL(m_z,16))+DWORD_TO_DINT(m_w);
rnd:=DINT_TO_REAL(u+1)*2.328306435454494E-10+0.5;I can't believe that people really want to do all the type conversions when they aren't necessary. No code is generated for the DWORD_TO_DINT or DINT_TO_DWORD or DWORD_TO_DINT so what is the point. However, one opcode is generated for the REAL conversions. Also, they could have used a shorter way of saying DINT_TO_DWORD. How about copying from others instead of making up your own crappy specifications just to be different? Why not do it like in C or java where DINT_TO_DWORD(number) is simply (DWORD)number.
Comments. I like comments. I like C or java comments.
I want to say
I=I+1 // increment I
instead of
I:=I+1 (* increment I *)
If is much easier to hit the same key twice than to (* *).
This is nuts. I don't see how (* *) improves on the tried and true //.
You can see I much prefer using = as an assignment and == as an equality check. I use assignments much more often than I use equality checks.
I have already specified that // will be allowed on our product. I must have // for line comments.
Hex numbers. What is wrong with 0xFFFF?. Again IEC had to make up some thing different. We already allow 0xFFFF as well as 16#FFFF on our product.
Standards limit creativity and searches for better ways of doing things especially when the standards are so flawed and yet so many think IEC is the only way to go.
Is there anybody here that seriously thinks the IEC specification is only way to go? I would prefer a C# or Java or even C++ with the pointers and the need for dynamic memory allocation.
I just wanted to stir thing up and by slamming the the IEC standard and the lemmings. We feel pressure to conform with the IEC specification but I don't think it is the right thing to do because it is flawed. I can provide examples if required. This lemming sees the cliff and feels like he is being pushed along by all the other lemmings. I also wanted point out there is a good way to generate pseudo random numbers is very quick and random enough.
programming. The influence of the archaic DOS-based Siemens approach is all too visible in 61131 standard.