Jump to content

Question about Program for making a dust colletor run


prak7121

Recommended Posts

Currently here is our program for making a dust collector run when 2 cutting torches are OFF or ON.

(Program below at the end of the post)

• Dust Collector running either VFD Default Speed or Speed 3 (EZIO2x4)

o …..this is a variable frequency drive that turns the dust collector off when the variable frequency drive is enabled (ON)

• Torch 1 is shown as P22 Sensor (IOLinc)

• Torch 2 is shown as P23 Sensor (IOLinc)

 

The program looks good to us and runs already here at my plant with zero issues.

But we keep getting an error where the variable frequency drive should be running the VFD-Default Speed when either one of P22 or P23 Sensors are ON.

We have a 3 minute delay whereby if either P22 or P23 or both are OFF, then the Speed 3 goes to ON.

 

The problem we have is that when the P22 or P23 sensors return to ON, the Default Speed should come back in a split second.

Instead we are seeing and measuring anywhere from 3, 5, 8, 15, 25 seconds randomly. On average 5 seconds is the main lag time but 3 to 25 seconds is not acceptable. My customer’s site fills up with smoke in 3-5 seconds. After 15-25 seconds I start to get nasty emails from my client.

 

Please can you help us and give us your opinion on whether we have done anything wrong?

 

Here is the program

 

If

Status 'P23-Sensor' is Off

And Status 'P22-Sensor' is Off

 

Then

Wait 3 minutes

Set 'VFD - Speed 3' On

Set 'VFD - Default Speed' Off

Send Notification to 'fansetback' content 'fanmotoroff'

 

Else

Set 'VFD - Default Speed' On

Set 'VFD - Speed 3' Off

 

One thing I want to add….we just discovered this. Both here and at my customer plant we are running both systems using the 3.3.5 firmware.

But at my plant we have the ISY99iIRPro but at the customer plant we are running the ISY994i

Here is a snapshot of their About:

post-1762-140474157594_thumb.jpg

Link to comment
The problem we have is that when the P22 or P23 sensors return to ON, the Default Speed should come back in a split second.

Instead we are seeing and measuring anywhere from 3, 5, 8, 15, 25 seconds randomly. On average 5 seconds is the main lag time but 3 to 25 seconds is not acceptable. My customer’s site fills up with smoke in 3-5 seconds. After 15-25 seconds I start to get nasty emails from my client.

 

Please can you help us and give us your opinion on whether we have done anything wrong?

 

Here is the program

If
       Status  'P23-Sensor' is Off
   And Status  'P22-Sensor' is Off

Then
       Wait  3 minutes 
       Set 'VFD - Speed 3' On
       Set 'VFD - Default Speed' Off
       Send Notification to 'fansetback' content 'fanmotoroff'

Else
       Set 'VFD - Default Speed' On
       Set 'VFD - Speed 3' Off

I think you should be using "Control" instead of "Status"...the "Control" will flip instantly. I would use one program to flip to default speed when either sensor comes on, and then another to change when both are off:

If
   (
           Control  'P23-Sensor' is Switched On
       Or Control 'P22-Sensor' is Switched On
   )
   And Status 'VFD - Default Speed' is not On

Then
       Set 'VFD - Default Speed' On
       Set 'VFD - Speed 3' Off
Else

======================================

If
   (
           Control  'P23-Sensor' is Switched Off
       And Status 'P22-Sensor' is Off
   )
   Or (
           Control  'P22-Sensor' is Switched Off
       And Status 'P23-Sensor' is Off
   )
   And Status 'VFD - Default Speed' is On
Then
       Wait  3 minutes 
       Set 'VFD - Speed 3' On
       Set 'VFD - Default Speed' Off
       Send Notification to 'fansetback' content 'fanmotoroff'

 

So the first program will quickly turn on default speed if it is not already on whenever either sensor switches on. In the second program, whenever a sensor turns off and the other sensor is already off, start the 3-minute timer to slow down.

Link to comment
Hi Vyrolan, are you 100% sure about the Control versus Status? I ask because we are doing this already at my company for 2 years using Status without issue. Mind you at my plant we only monitor 1 IOLinc whereas at this customer site we are monitoring 2 IOLincs.

I think both should work...but Control is specifically for the time when something changes...hence "is switched". The Status ones should also work, but I wouldn't necessarily expect them to respond as quick. If I say "when this is switched on, do X", it better do X as soon as the switch occurs. If I say "when this is on, do X", I can understand that it maybe only checks that every once in a while. It has other stuff to do so it doesn't get around to noticing that those are on as fast. I agree that logically they are the same for your purpose...both should produce the same result, and I'm no expert on the internals of how the ISY works, but I would certainly not be surprised if the Status ones were not triggered as fast.

 

A simpler fix might be to add some conditions to your program like this:

If
       Status 'P23-Sensor' is Off
   And Status 'P22-Sensor' is Off
   And Control 'P22-Sensor' is not switched On
   And Control 'P23-Sensor' is not switched On

Then
   Wait 3 minutes
   Set 'VFD - Speed 3' On
   Set 'VFD - Default Speed' Off
   Send Notification to 'fansetback' content 'fanmotoroff'

Else
   Set 'VFD - Default Speed' On
   Set 'VFD - Speed 3' Off

 

That way as soon as either Sensor switches On, the "is not switched On" becomes false and the Else runs. That might help it trigger faster as well.

Link to comment
If

Status 'P23-Sensor' is Off

And Status 'P22-Sensor' is Off

 

I am not sure I understand your system enough to critique your "then" or "else" path. But I can offer an opinion on your "if" condition. Perhaps my observations will give you an idea to help further troubleshoot,

 

Your "if" condition will trigger an evaluation at ANY change of status of EITHER sensors. When triggered, it will evaluate as "true" only if BOTH sensors are off. If one or both sensors are on when triggered, it will evaluate false and run the "else path".

 

Another thing that may happen is that the program may evaluate true and run the "then" path, which starts the three-minute wait period. If the program is triggered again before the wait period is over, it will halt execution and restart the "then" path or execute the "else" path, based on evaluation results. Could this be happening to you?

 

But we keep getting an error

 

What error? Is this an insteon error, or an error with your dust collection system?

Link to comment

Those are great questions and I am not sure I can answer them for lack of insight and experience. But I can say this.....if I change the STATUS to CONTROL, is there anything I can do to monitor the results other than waiting for the customer to report to me that the system is not turning on or off when it should be?

One example of my confusion is that I have seen the system not update (as it would update the status of each device after a Query) immediately. So I am concerned that the 2 IOLincs are experiencing changes through the limit switches they monitor but that the ISY is not seeing the changes in status and therefore there is a lag between the limit switches and IOLinc and the ISY. We have even raised all the devices in the large open space to make sure there is no loss of communication and that we have optimal lines of site for the RF. But when the limit switches are engaging the dust collector should be coming on quickly in just 2-3 seconds but instead we see anywhere from 5-25 seconds. We have even replaced the PLM and the ISY and put in 4 more access points to make sure the signal is consistent and not broken.

 

Plus I would say 1-2 times per hour we lose connection with either IOLinc or the EZIO2x4.

To the point that we created another program to run Query every 20 seconds. I hate having to do the query but it gives me some confidence that we are refreshing the devices to see their status.

 

Hopefully I have given you enough details to answer the question of what our errors are.

Link to comment

Any ideas that on a few things we can do to check and bolster our communications? We are pulling out our hair and my customer is extremely frustrated with me. I would be indebted for any help to eliminate the lag times and inconsistent activation of the EZIO2x4. No really, I am at my wit's end. The place is all 3 phase and we have done a great job of phase syncing the devices and we see the devices in the ISY GUI but the lag time is killing us. With the lag time we are thus getting the system being controlled by the IOLinc's via the EZIO2x4 not running or running at inappropriate times.

Link to comment

Are there Access Points on all three phases? I don't think Smarthome will support 3 phase questions so things are pretty much left to the customer to resolve.

 

Run Tools | Diagnostics | Event Viewer at LEVEL 3. Do whatever is necessary to trigger the Inputs and Outputs, watching the time stamps on the respective Insteon traffic as well as the Hops Max=x and Hops Left=y counts. Might be well to post an event trace showing a representation of the variours Inputs and Outputs being turned On and Off.

Link to comment
Those are great questions and I am not sure I can answer them for lack of insight and experience. But I can say this.....if I change the STATUS to CONTROL, is there anything I can do to monitor the results other than waiting for the customer to report to me that the system is not turning on or off when it should be?

 

If you simply change your existing program to substitute "control" for "status", I belive your program will ALWAYS evaluate as false. The use of control must be accompanied by other changes in your logic, as best I can tell.

 

My suggestion is to perform a few experiments. First, I would manually run the program's "then" and "else" path to confirm that your dust collectors are responding as you intend. If not, solve that problem first. It could be a communication problem or it could be a logic problem.

 

You could manually set vf - speed3 and vf - default. Does you dust collection system respond as you expect? Are you cofident that these are the correct command sequence? You could open an event viewer window and watch for evidence of communication problems.

 

You could check ISY-tracked sensor status and compare it to actual. When you turn on the two torches, did you confirm the IOLincs (LED) reflect this state? Does the ISY status follow the LEDs? If not, perhaps you have a communication problem.

 

Break your problem into smaller pieces to better understand which part is broken, then further to understand the root cause.

Link to comment

It has been mentioned that three phase power plus poor comm/noise is at the root of your problem.

 

I might suggest you consider re-configuring the phases so you can get everything Insteon on the same phase. Hopefully you can find one of the three phases that is not cluttered with noisy devices.

 

3 phase panels generally are such that every 3rd contact on the panel is of the same phase. If you swap the wires/breakers up/down one there is a good chance you can get all of your insteon devices to be on the same phase. It seems as though you only have few devices so probably very few modifications would be necessary to accomplish this.

Link to comment

Hello Prak7121,

 

Insteon communication issues can be tough to sort out in single phase residential environment.

Next most difficult would be a 3 phase residential or commercial environment.

What you have sounds like the worst, if a commercial/Industrial 3 phase environment.

 

Are you an electrician? If not I would not recommend swapping breakers around in a 3 phase cabinet. Many circuits share a common neutral and while you might help an Insteon issue you may also create an overloaded neutral condition.

 

It would be most helpful to diagram your install. How are the torches being sensed? What type of device and how long are the cables from the sensing device to the IOlincs?

IOLincs are not exactly industrial environment devices. There (5V) inputs are a low threshold of about 1 volt and only a couple of milliamps. That makes them more noise susceptible.

Especially if cable lengths are long.

Typical industrial controls run at 12 or 24Vdc to increase the noise margin.

 

In a commercial/Industrial environment you are much more likely to encounter electrical noise issues. VFDs are notorious for noise generation.

 

As has been mentioned try to identify where the issue might be occurring by testing and observing status leds and ISY logs. Do the LEDs go out completely or do they remain on dimly?

Make sure the IOlincs are sensing the at the very moment that the torches change state.

 

What is the incoming service, 480V or 208V ? Are there distributed step down transformers within the facility?

 

In a commercial/Industrial environment there are so many possibilities that a diagram is very helpful to begin to separate/identify possibilities and begin to eliminate some to zero in on the main issue. There may also be more than one contributor.

Link to comment

Assumptions:

1) 120v x 3 incoming power from the utility

2) Insteon devices are all plugged into standard 120v outlets going back to single pole breakers at the panel.

3) None of the 120v breakers that go to outlets that the Insteon devices are plugged into have significant loads (which they definitely would not if they are going to standard wall outlets.)

 

Swapping which of the 3 phases any of those single pole breakers take power off the grid from will have no impact on anything inside the building, including neutrals. Neutral trouble can come to bear if you change around your hots away from the breaker box (in a j-box for example). But if you are unsure of what you are doing, consult an electrician.

 

Not that this is a cure all. The 3 phase motors will of course be attached to all 3 phases so if one of them is noisy or attenuates signal, then you will have solved nothing since there is a good chance it will affect all 3 phases. Although, this is not for sure. Many times some components of a 3 phase device will only take power off of one of the three phases. For example, a 3 phase motor may have a control panel that is powered off of 120v, so if the control panel were noisy, the other 2 phases may survive unaffected.

 

An algorithm:

 

1) Identify which breakers power your Insteon devices.

2) Shut off all breakers except the one going to ISY

3) Turn on the breaker going to your first Insteon device. Test for comm reliability.

4) Repeat step 3 until all the Insteon devices are on.

5) If communciation between all the devices is reliable, start turning on additional breakers one at a time without powering on the loads connected to the breaker.

6) Repeat step 5 until all breakers are on

7) Once all breakers are on and if you still have not run into reliability troubles, start turning the loads on one at a time.

 

If at any time you lose reliability, turn that breaker or load off, tag it as a trouble maker, and move on.

 

If you are able to determine that you have one or more trouble makers, then consider how to solve that based on what is causing the trouble. Sadly, if it is a high amp device, you may be out of luck. Filters for high amps are very pricey and may just not be available depending on how many amps you are talking.

 

If your lucky enough to find a single phase circuit that is the root of your trouble, moving your Insteon devices off of that phase may be all you need. Or you may be able to filter that entire breaker (assuming no Insteon devices on the breaker and that it is 20 amp or less).

Link to comment

I'd be interested in seeing a wiring diagram on how swapping 2 single pole 120v breakers in the same box with the same neutral bar affects neutral load.

 

But that aside.

 

Might I make another suggestion.

 

You appear to have very few devices in this setup. At a glance it appears that they are all dual band.

 

Consider filtering all of your Insteon devices. Take the power line component completely out of the equation and let the RF do all the work. Of course if your devices are at a distance this won't work. But it is a thought.

 

Another thought would be to abandon Insteon and use IP. A global cache device can be controlled by the ISY network module but communicates over IP. Unfortunately, I don't believe they have a wifi version that would accommodate your needs. But you could use a wifi bridge if wired IP isn't available. You could also consider a webcontrol board. Same holds true regarding wifi. Perhaps there are other brands of devices I am unaware of that control relays over wifi IP natively that can run on the ISY network module.

Link to comment
Consider filtering all of your Insteon devices. Take the power line component completely out of the equation and let the RF do all the work. Of course if your devices are at a distance this won't work. But it is a thought.

 

This could work...he mentioned they had intentionally mounted the devices up high trying to provide clearance and good line of sight for RF.

Link to comment

apostolakisl,

Do you know what a MWBC ( Multi-Wire Branch Circuit) is? If not then you might google it and so some reading.

I do not have time to create a drawing right now.

 

Prior to the 2008 NEC , MWBC's were allowed on single pole breakers. Since 2008 they have to have a handle tie.

 

So it is possible for 3 single pole breakers to share a common neutral. Prior to 2008 they did not even have to be right next to each other in the panel.

If a person blindly starts moving breakers around the neutral can be overloaded.

 

If you understand the concept of a shared neutral and cancellations of current, in a 3 phase MWBC when all three breakers are on different phases, and the phase currents are equal, the neutral current is zero. Now assume that each phase is loaded to 16 amps. As properly installed the neutral current is zero.

If you now move these three breakers such that they are all on the same phase the neutral current will be 48 amps!

 

But don't take my word for it, do some research for MWBC.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...