Jump to content


OIF Fault Parameters


  • Please log in to reply
5 replies to this topic

#1 lambroffs

lambroffs

    Power User

  • Members
  • PipPipPipPipPip
  • 22 posts

Posted 11 January 2005 - 04:29 PM

I am using a Crestron controller to communicate with your amps (formerly MA5002VZ, but looking to switch to I-Tech 8000) using the UDP-IQ tools and OIF parameters.  Since I install these amps on US Navy ships, I need to be notified of every fault, large and small, sensed by the amp so that the Crestron controller can automatically switch to a redundant amp and also report an alarm to the duty technicians for investigation.  In the past I have used the AUX port to trigger an alarm.  Since the I-Tech has done away with the AUX port (although I did find a reference to it in the I-Tech manual paragraph 4.6.13 Error Reporting... which I think is a typo... right?) I need to fish for errors using the UDP-IP protocol.  My problem is that the OIF descriptors are not sufficient enough to figure out what I need to be monitoring.  I think I need the following:

- LINE VOLTAGE MONITOR / REPORT LVM VIA NETWORK
- POWER SUPPLY TEMPERATURE MONITOR (Is this part of Thermal Error?)
- IOC MONITOR / REPORT IOC ERROR VIA NETWORK
- REPORT SUPERVISOR ERROR VIA NETWORK
- THERMAL ERROR / REPORT THERMAL ERROR VIA NETWORK

Other OIF entries look promising, but I just don't know enough about them to know (i.e. Proportional VCC Monitor, Sharc workload, Power Supply Current).  Are there addtitional critical faults that I can access through UDP-IP that I have not listed?  Are there other faults tied to the front panel Fault Indicator that I can tap into?

Also, the UDP protocol says that application errors are only broadcast to controllers that have sent an idGetState within the past 30 seconds.  Can I send ANY idGetState to qualify, or does it have to be a poll of that specific error?  In other words, do I have to continuously poll all errors that I want to monitor?

Thanks.
Scott

#2 lambroffs

lambroffs

    Power User

  • Members
  • PipPipPipPipPip
  • 22 posts

Posted 14 February 2005 - 02:09 PM

Was my post not appropriate for this forum?  I am trying to fully utilize the UDP tool kit you freely distribute as it is allowing me to offer my customers some pretty high-level features that they aren't used to expecting from their system.  But, while the toolkit hints at the exciting possibilities tucked away in your I-Tech firmware, it doesn't provide enough as a stand-alone document to fully (or even partially) explain some available features.  Is there an alternate channel at Crown that I can use to answer my questions?  Have I stepped into the realm of fee-for-service engineering support?  Thanks.

Scott

#3 DGlass

DGlass

    .

  • Members
  • PipPipPipPipPip
  • 2,541 posts

Posted 18 February 2005 - 12:14 AM

Scott,
I am sorry that you feel this way about our documentation. The documentation is provided as a service for anyone who wants to develop their own control and monitoring with third party controls. We have had many people use it successfully nationally and internationally without any problem. When it is provided we tell everyone straight out that we do cannot support it other than providing it as each third party control system operates differently.
My apologies for the delay in getting you a response I will try to get you an answer as soon as I can. Since your posting on the "IQ Forum" we have moved to a new server and expanded to become the "Crown Forums" and were shut down for a while during this transition. It appears your question has fallen through the cracks. Again my apologies as we take all questions seriously and try to provide answers as best we can.

#4 lambroffs

lambroffs

    Power User

  • Members
  • PipPipPipPipPip
  • 22 posts

Posted 22 February 2005 - 09:37 AM

I was not critiquing your UDP-IQ Protocol Document.  I have had no problem using GET and SET on most OIF parameters.  I was commenting on the lack of available information on individual OIF parameters.  Your documentation tells me how to access the "Proportional VCC Monitor" value, but I have no avenue for deducing what the parameter means.  Most of the OIF parameter functions are obvious from the name alone, but others are obscure functions that apparently only those with "inside" information can deduce.   That is all I was saying.  Sorry for the miscommunication.

Scott

#5 Bradford Benn

Bradford Benn

    Power User

  • Admin
  • 1,025 posts

Posted 22 February 2005 - 07:26 PM

Hello-

I have asked checked for some additional information regarding error states and keeping a subscription open. Object 16385 lists all the possible error strings. ANY idGetState message qualifies to keep a subscription open.
-=Brad

Bradford Benn
Business Development Manager - Crown International
http://www.crownaudio.com/

#6 lambroffs

lambroffs

    Power User

  • Members
  • PipPipPipPipPip
  • 22 posts

Posted 20 April 2005 - 10:13 AM

From your last reply:
"Object 16385 lists all the possible error strings."

How do I call object 16385?  I tried issuing an IdGetState request and referenced
HEX [40][01].  I received the following error:  "error:  bogus object id in description: 16385".  I am running firmware v1.301 in an ITech8000.

I also get the same "error: bogus object id in description: 16272" when I query the Component Online status and "error: bogus id in description: 16312" when I query the IQ Address.  These last two are listed in the OIF file, while the error string object is not.  Any help is appreciated.  

If easier, it would be a huge help if you could cut-n-paste the error string dump to this forum.  Thanks.