You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old December 1st, 2017, 01:36 PM   #1
Sparkyman1
Member
United States

Sparkyman1 is offline
 
Join Date: Apr 2017
Location: Minnesota
Posts: 48
PowerFlex 525 Comm Loss detection.

Processor is a L32E

For some reason, I thought that there was a tag member that would give a status on Ethernet communications for a powerflex 525 VFD. But I cant find it anymore.

Currently program that i'm looking at is writing a negative value to the tag "I.OutputFreq" and then waiting for that value to be corrected by the VFD.

That system works for detecting com loss, but we've always had intermittent troubles with VFD's not starting when commanded (for no apparent reason) or not reaching the proper speed, faulting, or showing comm loss, and i'm wondering if writing to that tag (I.OutputFreq) could be the cause.


How do you guys detect when Ethernet communications to a PF525 are lost?
  Reply With Quote
Old December 1st, 2017, 01:55 PM   #2
keshik
Lifetime Supporting Member
Canada

keshik is offline
 
Join Date: Jun 2011
Location: Portland, OR
Posts: 396
Take a look at using a GSV.

Class Name: "Module"
Instance Name: Your device
Attribute Name: "EntryStatus"


From the help:
EntryStatus


INT


GSV


Specifies the current state of the specified map entry. The lower 12 bits should be masked when performing a comparison operation. Only bits 12...15 are valid.

Value
Meaning

16#0000
Standby: the controller is powering up.

16#1000
Faulted: any of the MODULE object’s connections to the associated module fail. This value should not be used to determine if the module failed because the MODULE object leaves this state periodically when trying to reconnect to the module. Instead, test for Running state (16#4000). Check for FaultCode not equal to 0 to determine if a module is faulted. When Faulted, the FaultCode and FaultInfo attributes are valid until the fault condition is corrected.

16#2000
Validating: the MODULE object is verifying MODULE object integrity prior to establishing connections to the module.

16#3000
Connecting: the MODULE object is initiating connections to the module.

16#4000
Running: all connections to the module are established and data is successfully transferring.

16#5000
Shutting down: the MODULE object is in the process of shutting down all connections to the module.

16#6000
Inhibited: the MODULE object is inhibited (the inhibit bit in the Mode attribute is set).

16#7000
Waiting: the parent MODULE object upon which this MODULE object depends is not running

16#9000
FirmwareUpdating: Firmware supervisor is attempting to flash the module.

16#A000
Configuring: Controller is downloading configuration to the module. Either ?forward open? or (ADC) download occur during this state.
  Reply With Quote
Old December 1st, 2017, 02:15 PM   #3
Sparkyman1
Member
United States

Sparkyman1 is offline
 
Join Date: Apr 2017
Location: Minnesota
Posts: 48
I completely understand what your telling me, all except for the "16#"
I'm not sure if i'm looking as ASCII characters, octal, or hexadecimal..

Quote:
Originally Posted by keshik View Post
Take a look at using a GSV.

Class Name: "Module"
Instance Name: Your device
Attribute Name: "EntryStatus"


From the help:
EntryStatus


INT


GSV


Specifies the current state of the specified map entry. The lower 12 bits should be masked when performing a comparison operation. Only bits 12...15 are valid.

Value
Meaning

16#0000
Standby: the controller is powering up.

16#1000
Faulted: any of the MODULE objectís connections to the associated module fail. This value should not be used to determine if the module failed because the MODULE object leaves this state periodically when trying to reconnect to the module. Instead, test for Running state (16#4000). Check for FaultCode not equal to 0 to determine if a module is faulted. When Faulted, the FaultCode and FaultInfo attributes are valid until the fault condition is corrected.

16#2000
Validating: the MODULE object is verifying MODULE object integrity prior to establishing connections to the module.

16#3000
Connecting: the MODULE object is initiating connections to the module.

16#4000
Running: all connections to the module are established and data is successfully transferring.

16#5000
Shutting down: the MODULE object is in the process of shutting down all connections to the module.

16#6000
Inhibited: the MODULE object is inhibited (the inhibit bit in the Mode attribute is set).

16#7000
Waiting: the parent MODULE object upon which this MODULE object depends is not running

16#9000
FirmwareUpdating: Firmware supervisor is attempting to flash the module.

16#A000
Configuring: Controller is downloading configuration to the module. Either ?forward open? or (ADC) download occur during this state.
  Reply With Quote
Old December 1st, 2017, 02:19 PM   #4
keshik
Lifetime Supporting Member
Canada

keshik is offline
 
Join Date: Jun 2011
Location: Portland, OR
Posts: 396
Basically, the GSV is going to return a DINT that is formatted in hexadecimal.

If, as part of the tag properties, you change the Style to "Hex" (bottom of the tag properties window) it will make a lot more sense.

You can then just do some pretty easy "EQU" comparisons to the result.

For example if "ResultTag" == "16#4000" (you can use the "16#..." prefix to a number to specify it as hexadecimal instead of decimal) then the device is running. If it's something else, it's not working properly.

These are the same values that are returned on the device properties screens (when you right-click, Properties on the device in the explorer tree).
  Reply With Quote
Old December 1st, 2017, 02:22 PM   #5
keshik
Lifetime Supporting Member
Canada

keshik is offline
 
Join Date: Jun 2011
Location: Portland, OR
Posts: 396
My advice would be to set up the device GSV, create a destination tag that is formatted as hexadecimal and plug in and unplug the Ethernet cable and watch what the value returns as. It should make sense then. You can continuously scan the GSV so it's pretty easy (don't need a rising edge). You may want to poll the device intermittently (use the .DN bit of a timer) at some point in the future to reduce things that the processor is doing but that's up to you.
  Reply With Quote
Old December 1st, 2017, 02:27 PM   #6
Sparkyman1
Member
United States

Sparkyman1 is offline
 
Join Date: Apr 2017
Location: Minnesota
Posts: 48
Found what I need, just like you described. thank you!

https://rockwellautomation.custhelp....NetIP_RevC.pdf
  Reply With Quote
Old December 1st, 2017, 02:53 PM   #7
Ken Roach
Lifetime Supporting Member + Moderator
United States

Ken Roach is offline
 
Ken Roach's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA
Posts: 13,922
That example is exactly how I do it. It's an example of the general GSV usage described in the Major, Minor and I/O Faults Programming Manual:

http://literature.rockwellautomation...m014_-en-p.pdf

With regard to the "drives not starting when they are supposed to"; take a close look at the logic and figure out when you're holding the STOP bit true.

The classic method of "If START is not asserted then assert STOP" always has the risk that the Output connection will grab the state of both bits exactly at the instant between the rung or line that controls the START and the one that controls the STOP. That will send both START and STOP true at the same time, which causes the drive to ignore START.

I handle this by only asserting STOP when the drive is still Active. That way it's always False when the logic comes around to start the drive again.
  Reply With Quote
Old December 1st, 2017, 03:09 PM   #8
Sparkyman1
Member
United States

Sparkyman1 is offline
 
Join Date: Apr 2017
Location: Minnesota
Posts: 48
I didn’t write the program, but I’ll defiantly look through it and figure out the sequence of commands.

Is it possible that the problem situation that Your describing would only present it self on an exremely rare basis?
  Reply With Quote
Old December 1st, 2017, 03:14 PM   #9
Sparkyman1
Member
United States

Sparkyman1 is offline
 
Join Date: Apr 2017
Location: Minnesota
Posts: 48
Quote:
Originally Posted by Ken Roach View Post
I handle this by only asserting STOP when the drive is still Active. That way it's always False when the logic comes around to start the drive again.
So you assert the stop bit before you turn off the start bit, and then you turn off the stop bit before asserting the start bit?

Last edited by Sparkyman1; December 1st, 2017 at 03:16 PM.
  Reply With Quote
Old December 1st, 2017, 03:14 PM   #10
OkiePC
Lifetime Supporting Member
United States

OkiePC is offline
 
OkiePC's Avatar
 
Join Date: Mar 2005
Location: ENE of Nowhere Oklahoma
Posts: 9,782
Quote:
Originally Posted by Sparkyman1 View Post
I didn’t write the program, but I’ll defiantly look through it ...
Story of my life right there...
__________________
It's not all the variables I am most concerned with, it's the undiscovered constants.
  Reply With Quote
Old December 1st, 2017, 03:16 PM   #11
Sparkyman1
Member
United States

Sparkyman1 is offline
 
Join Date: Apr 2017
Location: Minnesota
Posts: 48
Quote:
Originally Posted by OkiePC View Post
Story of my life right there...
Lol, my autocorrect stopped correcting that one for me.
  Reply With Quote
Old December 1st, 2017, 04:28 PM   #12
Ken Roach
Lifetime Supporting Member + Moderator
United States

Ken Roach is offline
 
Ken Roach's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA
Posts: 13,922
The simultaneous START + STOP bit issue tends to appear infrequently. Not only does the I/O connection RPI timer have to expire between scans of those two specific lines of the program, but also the drive has to be commanded to start to expose the conflict.

The goal is to have the .START bit true only until the drive confirms it is running by setting the .ACTIVE bit true.

Likewise, we set the .STOP bit true only until the drive confirms is has stopped running by setting the .ACTIVE bit false.
Attached Images
File Type: png StartStop.PNG (8.0 KB, 137 views)
  Reply With Quote
Old December 2nd, 2017, 01:11 PM   #13
Sparkyman1
Member
United States

Sparkyman1 is offline
 
Join Date: Apr 2017
Location: Minnesota
Posts: 48
Quote:
Originally Posted by Ken Roach View Post
The simultaneous START + STOP bit issue tends to appear infrequently. Not only does the I/O connection RPI timer have to expire between scans of those two specific lines of the program, but also the drive has to be commanded to start to expose the conflict.

The goal is to have the .START bit true only until the drive confirms it is running by setting the .ACTIVE bit true.

Likewise, we set the .STOP bit true only until the drive confirms is has stopped running by setting the .ACTIVE bit false.
Thanks for clearing that up for me, I'm really surprised to hear that the drive is fine with not having an active start bit while its running. I assume that it will stop on its own if it looses communication with the controller, or else you would never be able to stop the drive.
  Reply With Quote
Old December 3rd, 2017, 12:59 PM   #14
rupej
Member
United States

rupej is offline
 
Join Date: Sep 2014
Location: NC
Posts: 374
Quote:
Originally Posted by Ken Roach View Post
The simultaneous START + STOP bit issue tends to appear infrequently. Not only does the I/O connection RPI timer have to expire between scans of those two specific lines of the program, but also the drive has to be commanded to start to expose the conflict.

The goal is to have the .START bit true only until the drive confirms it is running by setting the .ACTIVE bit true.

Likewise, we set the .STOP bit true only until the drive confirms is has stopped running by setting the .ACTIVE bit false.
Anything wrong with just holding the start command active always when you want the drive to run, and then holding stop whenever start is not on? Seems like that would also fix the "no start" issue and also take two fewer bits in the logic.
  Reply With Quote
Old December 3rd, 2017, 01:50 PM   #15
Sparkyman1
Member
United States

Sparkyman1 is offline
 
Join Date: Apr 2017
Location: Minnesota
Posts: 48
Quote:
Originally Posted by rupej View Post
Anything wrong with just holding the start command active always when you want the drive to run, and then holding stop whenever start is not on? Seems like that would also fix the "no start" issue and also take two fewer bits in the logic.
I think what your describing is exactly what he was saying should be avoided, if you did that its possible that drive read info after the start bit turns on, but before the stop bit gets turned off, even if its the very next line of code.
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Powerflex 525 PID Controll for a Pump in a Hot Water Set travisroberts88 LIVE PLC Questions And Answers 18 November 10th, 2017 06:24 PM
PowerFlex 40 Comm loss icehube LIVE PLC Questions And Answers 0 April 17th, 2017 07:47 PM
Powerflex 525. Ethernet loss CallumMacEwen LIVE PLC Questions And Answers 11 August 24th, 2015 06:16 AM
Powerflex 525 Detecting Loss of ethernet connection DAnderson LIVE PLC Questions And Answers 1 December 29th, 2014 11:30 AM
RSLogix 5000 and Powerflex 525. Elcan LIVE PLC Questions And Answers 4 October 28th, 2014 10:38 AM


All times are GMT -5. The time now is 08:48 PM.


.