Combining bytes to form 32 bit value (24 bit)

[p.erasmus]

Leigh
Why is it always a case you guys cannot reproduce my reports (So I am stupid) I am waiting now 8 weeks for an answer on SD card read problem which you guys also asked for the FC chart , Now you do a dummy shift with my code byte values on Ghost and tell me what you see Eblock BL0080 and PIC161938 if you cannot or do not want it also fine I am tired of Ghost, I mentioned many reports which always get water down to my stupidity and that is where it stays for today I had enough of this I am in a bad mood sorry if you solve this issue or not I am done !!!

[kersing]

Can you change the hi/mid/lo variables to unsigned long as well? Shifting an unsigned byte might result in it not being promoted to the right data type by the compiler which might result in your issue.

[p.erasmus]

I did all of these tricks Jac Thanks for the suggestion

In another tool chain I can even just shift the sigle bytes into position and it change corecrctly I tried all metods indicated here and my standard method for many years an all are working it in FC/X8 with ICD that I see wrong things

Here I just shifted the the individual bytes in to position result correct

P5.jpg (23.23 KiB) Viewed 3228 times

[p.erasmus]

Just as information this whole communication protocol was developed with using Comms Simulation with Scada all worked perfectly and i could move the input voltages any way positive till negative from 0- full scale.
Then exported the component programmed it on a PIC and I only have negative values all the time then activating the source code on the BL0080 and ICD to see what is the reason is and I saw this that the returned value is all ways FFFFxxxx.

which is confusing if the Scada is working correctly , why it does not work on the PIC generated code ?
The question to me is in SCADA sim who is handling this shift operations in code FC I suppose and on the PIC it is the XC8 compiler generated code
this also means to me that trusting only on SCADA to develop the Comms component is dangerous and all components should be tested on real HW

Trying to understand the road forward with this scada development or going back to EBlock and FC

[BenR]

There's a type conversion component that might help with stuff like this and it has the added bonus of converting between bytes, ints, longs and floats.

It works equally well in the sim and on hardware and it also doesn't use shifts so should be very fast and reliable to use.

Shifts of 16 and greater are always a good one to look out for.

[p.erasmus]

Hi Ben

Thanks however I did not understand how to use the type conversion ,I looked at it and did not understand what to use
getLong or Setlong and in both cases I did not see how to pass 3 bytes into the call to get out a Long number,then decided to go with the old shifting style ,
Can you please show me how to use this as I do not understand the help file either there is no explanation how to use it I am sorry for me I do not understand this help file

P1.jpg (8.31 KiB) Viewed 3206 times

P3.jpg (10.56 KiB) Viewed 3206 times

P2.jpg (40.83 KiB) Viewed 3206 times

I understand your view on the shifting and believe you Ben, however for years I have been using shifting and never had this problem(Running this code yesterday with another ICD and tool it works as always
It is working in FC with SCADA only when in Ghost debugging( on PIC)it is not working which I do find strange

[p.erasmus]

Hi All.
All is good Martin helped me to understand the TypeConverion Component