[Clas_online] JInventory

[boiarino at jlab.org]

Hi Dave,
based on our experience we do not want to assign/label cables in according
to boards they are suppose to be plugged in, even knowing that in most cases
such relation is quite solid. The main reason is that some cables will be
replaced
by new ones for whatever reason (broken, new wiring etc), and old cables
usually hung around carrying board-related labels which is confusing.
Relabeling
cables may create even bigger mess, and usually is not done at all. In the
proposed
scheme main cable labels will not have board references, it will be
through numbering
for all cables in the Hall, with connector number after '-', for example
coax signal cable
will be labeled abc123-1 on one end and abc123-2 on another one, and those
will be
cable connectors names. Technicians usually run cables from rack to rack,
so cable
connector locations will be rack ids, not board id and not even crate id.
   Boards connectors will be named differently for different board types,
usually using
whatever graved on the board front panel. If nothing is graved, we may
put/write
our own notation, so technician can clearly see connector ids looking on
the board.
   So when it will come to actual connection process, cable connector id
will be on
the cable near the connector, and board connector id - on the board front
panel.
Technician will use connection table to make actual connection and change its
status to 'connected'.
   Another way is to label cables in according to boards they are
connected, lets
collect more comments and then we'll have another meeting.
Regards, Sergey

>
> Hi Sergey,
>
>    Perhaps this has already been discussed, but I have a couple of
> questions/
> comments on the proposed cabling schema:
>
> 1.) I'm not sure I understand the need for the red CONNECTION
> table. It seems that the "board_connector_id" column could be
> placed directly in the cable CONNECTOR table. The connected/
> disconnected state seems implicit by virtue of having an entry
> in the cable CONNECTOR table or no entry that points to the item
> CONNECTOR table.
>
> 2.) How is the location in the cable CONNECTOR table different
> from that in the ITEM table? (It seems all the information regarding
> board and connector on board is already in the ITEM and item
> CONNECTOR tables.)
>
> 3.) You might consider adding a something like a "protocol" column
> to the CABLE table to hold something like "NIM", "Single-ended ECL",
> etc. ... This would allow you to search cables based on that.
>
> Otherwise, it looks pretty good. It seems flexible enough to
> handle the bizarre hybrid cables the DAQ system sometimes
> requires.
>
> Regards,
> -David
>
> On 3/17/12 12:08 AM, boiarino at jlab.org wrote:
>> Dear colleagues,
>> attached is the proposal how cables can be presented in the inventory
>> system,
>> based on our previous discussions.
>>
>> Some comments:
>> * ITEMs are exists in the system already, they will stay untouched; if
>> some of them
>> (like boards, crates, devices etc) have connectors, those CONNECTORS
>> will
>> be kept
>> in the separate table, and every connector will have reference to the
>> host
>> board,
>> as well as unique id, type, name and any other necessary information;
>> connectors
>> will NOT have a location, since they are associated already with ITEMs -
>> see blue
>> frame
>> * new object called CABLE will used; similarly to the ITEM-CONNECTOR
>> relation,
>> every CABLE may have several CONNECTORS kept in separate table, and
>> every
>> connector will have reference to the host cable; main difference from
>> the
>> ITEM-CONNECTOR is that location will be associated with the CONNECTOR,
>> not CABLE, it will allows to describe cable ends locations which we are
>> really
>> interested in; another difference from ITEM-CONECTOR is object called
>> WIRE,
>> which will be kept in separate table and describe wiring between
>> particular pins
>> in specified connectors - see green frame
>> * CONNECTIONS is another new class; it will describe connection between
>> ITEM_CONNECTOR and CABLE_CONNECTOR, which can have status 'connected'
>> or 'disconnected' - see red frame
>>
>> Following operations can be anticipated:
>> 1. ITEM (board, crate, device) record creation: as soon as item type is
>> specified,
>> script suppose to check if that particular type have any connectors, and
>> if so,
>> make corresponding entries in CONNECTOR table; those connectors will
>> have a reference to the ITEM unique id and will exist as long as ITEM
>> exist, and
>> must be deleted if corresponding  ITEM is deleted
>> 2. CABLE creation: when cable type is selected, script suppose to offer
>> corresponding
>> GUI to fill necessary fields, and after all info is typed in, make all
>> necessary entries
>> in 3 tables: CABLE, CONNECTOR and WIRE; it should be mentioned that for
>> most of
>> cables GUI will be rather simple: whoever will make a cable, will be
>> asked
>> to enter
>> cable id, label, type and 2 connectors; connectors location are not
>> filled
>> at that
>> time
>> 3. CONNECTION creation: can be done during actual connection, or in
>> advance
>> setting status to 'disconnected'
>> 4. Installation: by the time technicians have to install ITEMs and
>> CABLEs,
>> all those objects must be
>> in the database; after installing ITEM, technician will enter its
>> location; after running
>> cable, he will enter its connectors locations; and finally after
>> connecting cable to the
>> ITEM, he will make CONNECTION entry (or change its status to 'connected'
>> if connection
>> is in the database already)
>>
>> This is the scenario I have for now, hope it will be good starting point
>> for discussion.
>>
>> Regards, Sergey
>