Sign in to follow this  
Followers 0
whitenight

Runtime Byte Swap Problem

15 posts in this topic

My problem is this: I have a computer connected to an HC900 PLC for monitoring purposes, now when I start runtime and go to the overview screen in my program, random sets of #'s pop up and disappear all over the screen, I am told this is a byte swap configuration issue in windows, I don't know anything about this and my internet searches have not yielded any information on how to solve this problem, any help would be appreciated

Share this post


Link to post
Share on other sites
What you are seeing is the difference between Intel and Motorola data formats. Typically Modbus Devices use he Motorola format which is for the data in a register to be Read as hi lo meaning that the first byte is the hi byte. this is how it would apear in the scientific calculator in windows. Os if your device sent 0x00 0x01 the value would be read as 1. Now the tricky part if your software is set to read it in intel format it would use the lo hi format so the value would now be 256. It is important that you read the data using the same format that it is sent in. This realy has noting to do with windows and everything to do with the configuration of your communication package.

Share this post


Link to post
Share on other sites
You do not say if this problem persists. If it is a random event at start up then it is unlikely to be a byte swap problem, if it is persistant and consistently wrong then it could be.

Share this post


Link to post
Share on other sites
I can't change any configuration parameters on the HC900 itself because the controller is already communicating to another computer in the same room that the controller is in, this PC that is having the flashing numbers problem in runtime is only for monitoring purposes, it does not run anything, so if any changes are to be made they need to be done either to windows or the program on that particular machine

Share this post


Link to post
Share on other sites
1) Is this a Honeywell HC900 hybrid controller? If not, what brand HC900 is it? assuming it is a Honeywell: 2) Is this problem appearing on a Honeywell brand Operator interface? If so, do random numbers appear or disappear on the Honeywell O/I? If so, please describe which screen, like 4 controller faceplates, or digital in/out status matrix this occurs on. 3) How long does the problem persist? 1 minute during start-up? 15 minutes after start-up? All day long? 4) What do you mean by "starting runtime" Isn't the controller always in runtime mode? What are you doing to get into 'runtime' mode? 5) a) What software (name, version, revision) are you running when you look at an overview with a PC? b) Is this software communicating via the ethernet port on the HC900 controller? c) describe what screen the software is displaying when 'random numbers pop up and disappear all over the screen' 6) How does the 'other PC in the room' prevent you from changing configuration parameters? Have you made some configuration changes that started this random number display action? 7) How would you 'change configuration parameters', if the other PC were not somehow preventing you from doing so? What software would you use, which PC, the one with the random numbers or the other one? 8) How many PCs are involved with this setup? The purpose of each, with respect to the HC900 is . .? Dan

Share this post


Link to post
Share on other sites
1) Is this a Honeywell HC900 hybrid controller? If not, what brand HC900 is it? -Yes, this is a Honeywell HC900 Hybrid Controller 2) Is this problem appearing on a Honeywell brand Operator interface? If so, do random numbers appear or disappear on the Honeywell O/I? If so, please describe which screen, like 4 controller faceplates, or digital in/out status matrix this occurs on. -This problem is appearing in the runtime process of Citect Version 6.1, in the runtime screen the #'s appear and disappear all over the screen at random 3) How long does the problem persist? 1 minute during start-up? 15 minutes after start-up? All day long? -as long as the runtime process is active this problem persists 4) What do you mean by "starting runtime" Isn't the controller always in runtime mode? What are you doing to get into 'runtime' mode? -In citect you can activate the runtime function to bring up the operator interface and the see data that the controller is gathering from whatever machine it is plugged into 5) a) What software (name, version, revision) are you running when you look at an overview with a PC? b) Is this software communicating via the ethernet port on the HC900 controller? c) describe what screen the software is displaying when 'random numbers pop up and disappear all over the screen A.) Citect Version 6.1 B.) Yes, the controller has only one ethernet port, since there are two PC's attached to the controller (one for monitoring and one for functionality) the one ethernet port is attached to a small 5 port network switch C.) This all occurs in the runtime screen, Citect contains a graphics builder as part of the software package, meaning that we are allowed complete autonomy when it comes to creating a program based upon the customers needs...so each runtime screen is always different 6) How does the 'other PC in the room' prevent you from changing configuration parameters? Have you made some configuration changes that started this random number display action? -The other PC does not prevent me from making any changes, this other PC is in the same room as the controller and the machine where data is collected ETC....since this PC already successfully communicates with the controller and does not have any random #'s popping up all over the place I am not going to alter that setup in anyway. No, I have not made any config changes to make this # problem appear. 7) How would you 'change configuration parameters', if the other PC were not somehow preventing you from doing so? -See #6 What software would you use, which PC, the one with the random numbers or the other one? -I am using both, the PC having the problem is in another room altogether and does not run the actual machine, it is only for monitoring purposes 8) How many PCs are involved with this setup? The purpose of each, with respect to the HC900 is . .? -2, I think I have already explained the setup, any more questions let me know, thanks

Share this post


Link to post
Share on other sites
Just a side note. Are you sure it is only displaying # or does it display #COM ? In that case your driver is just experiencing comms time out. When Citect communications to a I/O device fails, by default all objects display #COM. Could be that it is constantly timing out and reconnecting. I searched my folder of Citect user list e-mails and found attached information. Perhaps it is of any help. If not, I'll kindly step out again as I have zero experience with Honeywell controllers *P.S. see the second document, MODNET[FloatMode] parameter. It refers to the byte order of the variable types.... Citect_HC900.pdf Citect_Honeywell_HC900_Communications_Configuration.pdf

Share this post


Link to post
Share on other sites
OK so that's not the case. Still have you read through the byte order part in the second document? Perhaps it can't hurt to check your config according to this document, seems like a pretty reliable instruction.

Share this post


Link to post
Share on other sites
The HC-900 is known to work well in Modbus TCP slave mode with multiple Modbus TCP masters, so if each PC is its own Modbus master, then the HC-900 should function well in that mode. If citect runs server based with web HMI's or thin clients with a single Modbus TCP master, then HC-900 would handle that OK, as well. The HC-900 has a default Modbus map, or the HC900 Modbus map can be custom configured to move specific parameters to contiguous Modbus register locations for multiple parameters read requests from a master. If the HC-900 data is showing up OK on one of the PC HMI's then, it it seems to me that the problem on the other PC HMI must be a Citect configuration issue. I'm not sure why a byte swap issue would create the described symptom of displaying values at random locations. But I can understand that the display might flash the wrong values due to the byte swap problem because byte swap always produces extremely large values, like, ±xx.xxx^17 or some such silly number; and I've seen other HMI's flash the value when provided with out-of-range values. Where the values get placed on the screen is a Citect configuration issue, unrelated to the HC-900. Dan

Share this post


Link to post
Share on other sites
That is precisely the issue I am having: large values like ±xx.xxx^17 appearing at random

Share this post


Link to post
Share on other sites
If I've understood you, it appears that there are at least two problems: 1) displayed values appear where displayed values should not appear, at random locations on the screen. 2) The displayed values are probably byte swapped, since they are way out range, like ±xx.xxx^17, typical of byte swapped values. Both problems are related to the configuration/programming of Citect, since the Citect 'program' is responsible for - which values Citect reads from the Honeywell controller - what happens with the values it reads (logs to history file, display, use for alarm, etc) - where and when it displays received values The byte swap issue is typically resolved by the Modbbus master, in which it is established which format is used. Although the Honeywell can remap its Modbus values in slave mode, I'm not sure whether the byte format can be changed from the default floating point byte format. I'll see if I can confirm that or not. I scan read some of the notes attached above, it appears that there's some clarification on how Citect handles (changes) floating point byte formats. Dan

Share this post


Link to post
Share on other sites
If I've understood you, it appears that there are at least two problems: 1) displayed values appear where displayed values should not appear, at random locations on the screen. -this is correct 2) The displayed values are probably byte swapped, since they are way out range, like ±xx.xxx^17, typical of byte swapped values. Both problems are related to the configuration/programming of Citect, since the Citect 'program' is responsible for - which values Citect reads from the Honeywell controller - what happens with the values it reads (logs to history file, display, use for alarm, etc) - where and when it displays received values The byte swap issue is typically resolved by the Modbbus master, in which it is established which format is used. Although the Honeywell can remap its Modbus values in slave mode, I'm not sure whether the byte format can be changed from the default floating point byte format. I'll see if I can confirm that or not. I scan read some of the notes attached above, it appears that there's some clarification on how Citect handles (changes) floating point byte formats. Dan

Share this post


Link to post
Share on other sites
on another note, I just came across another problem yesterday afternoon, when I fire this same program now, in addition to the ongoing issue with the random #'s, I also enountered this following error: "failed to load database_'Groups' file not found"....any ideas on this one, nothing ive found online helps, Citect's Knowledge base is useless for solving this problem

Share this post


Link to post
Share on other sites
Sounds like Citect cannot find the groups database file. How it has gone lost I don't know, but have you tried to compile the project (switch off incremental compile at project editor > tools > options) ?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0