Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

I/O Disturbance

Created by: Wasp at: 7/6/2011 11:24 AM (6 Replies)

Rating (1)

Thanks 3

7 Entries

7/6/2011 11:24 AM	Rate (0)
Wasp Posts: 28 Rating: (1)	Hi All, Something very unusual occured yesterday while comissioning a new FC for the reading in and outputing of analog signals on ASI bus. I configured temporary variables, within the FC in question, of different data types which were to be used in conjunction with the FC106 "UNSCALE" function, namely one BOOL, one DINT and one REAL variable. After programming I tested the code to ensure the correct scaling and values were being output, everything seemed OK. I then proceeded to test the newly programmed code by running the Production Line in automatic mode, this is when I noticed one of the LENZE drives, connected via Profibus to the PLC, was acting funny. The drive, which was previously working, moved with a jerk kind of motion as if it was mechanically jammed. The drive is released via start/stop signals configured within a Profibus word and saved as temporary variables within another FC. So after some fault finding I noticed that when I replaced the temporary variables(BOOL,DINT,REAL), configured in the FC for processing of analog signals, to a memory bit, word and double word the drive functioned normally. FC5 - Processing of analog signals FC30 - Lenze drive signal processing FC106 - Siemens library UNSCALE function DB5 - Data block for processed analog values DB30 - Processed Lenze drive signals I/O 280 - 295 - Configured IO range for profibus comms with drive I/O 256 - 271 - Configured IO range for ASI master The analog signals have absolutely nothing to do with the drive in question and are used for proportional control of a glue applicator system. My assumtion is that the Temporary variables I configured in FC5 somehow overwrote the values of the temporary variables I configured in FC30 for profibus communication causing the drive to receive a fuctuating start/stop signal. Ok, so everything is working now as I said, but would really like to know how this could be possible... If anyone has any idea please share your thoughts, would like to prevent something like this happening in the future. Warm Regards
Wasp Posts: 28 Rating: (1)
Suggestion To thank Quote Answer

7/6/2011 11:48 AM	Rate (0)
Aliende Posts: 18 Rating: (3)	I think this is normal. If you won’t to save or not overlaps some values- status use DB memory area or markers. In my experience is good to use FB with instance DB, and stat variable. Best regards
Aliende Posts: 18 Rating: (3)
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users Wasp

7/6/2011 12:15 PM	Rate (0)
Wasp Posts: 28 Rating: (1)	Hi Aliende, Any idea how and to which memory range Simatic assigns these temporary variables and how it could happen that they overlap? This is the first time that I have experienced an "Overlap" of sorts, or at least I assume thats what happend... Regs
Wasp Posts: 28 Rating: (1)
Suggestion To thank Quote Answer

7/6/2011 12:23 PM	Rate (0)
Aret Posts: 2348 Rating: (262)	Please check your motors FC to ensure you dont read temp variables before writing them.
Aret Posts: 2348 Rating: (262)
Suggestion To thank Quote Answer

7/6/2011 12:26 PM	Rate (1)
fritz Diamond Expert Joined: 10/7/2005 Last visit: 9/23/2023 Posts: 2987 Rating: (1034)	HelloWasp one explanation would be incorrect usage of TEMP variables in your FC30 (the Lenze drive control FC) in which casethe addition of the new FC5 can cause the problem (which is still a problem in FC30 though). Have a look at the link below for more on why it may have worked before and why it doesn't work anymore when TEMP variables are used incorrectly: Latching by temporary variable inside FB or FC- recommended I hope this helps and please let us know what you find (or upload your program here for further evaluation)
	Cheers fritz The advice and opinion given in this thread is that of the author and does not necessarily reflect the views of I S Systems Pty Limited. To find out how I S Systems can help you with your automation needs please visit www.issystems.com.au.
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users Wasp

7/6/2011 12:44 PM	Rate (0)
Wasp Posts: 28 Rating: (1)	Hi Aret, Well the FC is as follows: Network 1: I use SFC14 (DPRD_DAT) to read in the profibus words and store them as temporary variables within the FC. Network 2 - 7: In these networks the temporary variables are processed and changed accordingly. Network 8: I use SFC15 (DPWR_DAT) to write the current standing of the temporary variables to the drive. I am pretty sure this is correct. Additionally, this has been working for months now and only started gving problems yesterday when I downloaded and tested the new FC for processing the Analog signals. Regs
Wasp Posts: 28 Rating: (1)
Suggestion To thank Quote Answer

7/6/2011 1:12 PM	Rate (0)
Wasp Posts: 28 Rating: (1)	Hi fritz, Thank you very much for the link, it was very informative and I now realize were I went wrong. I never reinitialized the temporary variables on calling the FC and therefore experienced these uncharacteristic values during program operation. I guess I should have figured that the values would not be stored for a complete scan cycle, hence why they are called temporary variables . As you and Aliende said temporary variables cannot be relied on to store non-volatile data and is therefore best practice to utilize a defined memory area such as a DB or memory bit/byte/word etc. Thank you all for your posts. Warm Regards Wasp
Wasp Posts: 28 Rating: (1)
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users fritz

|

Share this page:

Share this page on...

Follow us on