1 / 12

ECS 2.0 The Big Upgrade

ECS 2.0 The Big Upgrade. ( from the ODE point of view ). Summary. The Firmware /Software current Status Improving the configuration speed. The Firmware /Software current Status. ELfOmain

anne-hays
Download Presentation

ECS 2.0 The Big Upgrade

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ECS 2.0The Big Upgrade (from the ODEpointofview) ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  2. Summary • The Firmware/Software current Status • Improving the configurationspeed ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  3. The Firmware/Software current Status ELfOmain ELfOmain, the firmwarerunning in the ELMB controllersof the ODE boardsiscurrently at itsversion 1.6-OD1.5 and wasinstalled on May, 12, 2011. The maincharacteristicsofELfOmain can belistedasfollow: • Itimplementsquitecompletely the CANopen standard, performingall the servicesimposedby the so calledPredefined Connection Set (thatis a subset of the standard CiA: DS301, DS401) • Itprovides a CANopen SDO server for reading and writing the ODE Object Dictionary of about 480 objects (expedited message transfer and segmented transfer) • Itprovides the capabilitytostore up to4Kbytesofconfiguration data. Currentlyonlyabout300bytes are actuallystored. The data stored can beautomaticallyapplied at the reset. • Itprovides a quitesofisticatedmechanism, completelyconfigurable via CAN, tomonitoring and surveillanceof the whole set of the configuration data ofan ODE. • Itimplements a rich set of custom emergencymessages, automatically sent to the host via CAN whensomething wrong happens ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  4. The ELfO EEPROM memory map ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  5. The ELfOmainloop (simplified) ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  6. The Firmware/Software current Status OdeMon OdeMon, the PVSS software running on the 4 PC dedicatedto the ODE boardscontroliscurrently at itsversion 2.0.2 and wasinstalled on Feb, 23, 2011. The maincharacteristicsofOdeMon can belistedasfollow: • Ithas a double mode ofoperation: as a stand-alone controlprogram (with no link to the FSM of the ECS), and as a Device-Unit , wellinsertedinto the hierarchyof the MuonFSMs • Startingfrom a mainpanelItprovides a hugenumberofchildpanelsthat are specificformanydifferent set ofcommands . All the registersofall the ODE boardsof a wholequadrant (38 ODE boards) of the LHCbMuonapparatus can beread or written ( ~ 18.000 registers) • All the ELMB ofall the ODE boards are under the controlof the program and a continuousexchangeofinformationsisaccomplished in background. ThishappensonlywhenOdeMonis in itsDU-modeofoperation ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  7. The Firmware/Software current Status CAS The currentversionofOdeMonhasintroduced the Control and Alarm System for the ODE boards. The CAS’s duty is to detect any abnormal condition of operation and to generate an appropriate warning to be published on the central console in the control room. The CAS is implemented both in firmware and in software . By the firmware two different tasks will be accomplished: the Monitoring task and the Surveillance task: • the Monitoring is the comparison of the current configuration values ​​read from the registers of an ODE board with the last recipe applied. The Monitoring will examine exclusively the R/W registers • the Surveillance is the comparison of the current values read from the registers of an ODE board with the reference values stored into the EEPROM of the ELMB controller. The Surveillance will examine exclusively the RO registers plus some memory locations of the ELMB itself and the OPC-server behaviour For every detected difference an appropriate Emergency Message will be sent to OdeMon that will process the message , extracting several informations. ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  8. The Firmware/Software current Status CAS With the informationsabout the occurredemergency the CAS will decide howtomanageit, but in principle: • itwill stop the controloperationsof the firmware • itwillforce the CANopen FSM intoPREOPERATIONAL state • itwillpublishan appropriate alert on the central consolle of the controlroom • itwillforce the FSM of the relative DU intoanERROR state OdeMonprovidesmanyspecialized routine torecoverautomaticallyanabnormalcondition, so that in manycircumstances the User, beforetobetemptedtoreset the wholepartition, shouldhavetotry the “Recover” commandonto the DU in ERROR state. If the “Recover” commandwillbesuccessfully: • the firmwarewill start again the controloperations • the CANopen FSM willbe put intoOPERATIONAL state • the alertwillbecleared on the central consolle • the right valueswillberecoveredinto the affectedregisters • the FSM of the relative DU willbe put into the state itwasbefore the alarmhappened ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  9. The Firmware/Software current Status Conclusions The CAS is now almost completely disabled. The inability to be able to make accurate tests with the experimental apparatus in operation, and the excessive sensitivity of the cas itself, with a tendency to generate false alarms, has made it essential to its deactivation. Severaltestswillbeneededbefore the CAS willbeactivatedagain. Further, a more euristicalgorithmis under implementationtomake the CAS smarterthannow . . . CurrentlyOdeMonruns on 4 PC, one per quadrant. Thisarchitectureisneededtoovercome the complexityof a hugeamountofdata-pointsbutforces the usertorepeat the sameoperationsforfourtimewhenhe/shewillapplysomething on the wholeMuon System. a new version of OdeMon is being studied to overcome this limitation and to make it possible to act by any of the 4 PC on the w.hole apparatus. ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  10. Improving the configurationspeed When the “Configure” commandis sent by the ECS system to the ODE boards, a configuration data recipewillbeapplied. A data recipeforconfiguring just oneODEboardisconstitutedby477data bytesthat, forconvenience, are groupedin littlesubsetscontainingfrom 1 to 4 byteseachone. A total of 190 subsetswillconstitute the variousitemsof the ODE recipe, afterbeingorderedinto a rigid format . Currently, for the purpose to use the function fwConfigurationDB_applyRecipe() of the Framework, so as it is, without changes, the protocol currently used by the Firmware of the ODE’s ELMB for a recipe downloading is the so-called expedited mode of the CANopen standard. The standard CANopen cites three main protocols for the transactions of the SDO (the transaction to read/write into the OD): • The normal mode also called segmented mode, where a transaction is constituted by many CAN frames, all confirmed, and with a maximum of 7 bytes of useful data • The expedited mode, a particular segmented mode with just one segment and a maximum of 4 bytes of useful data. This is the mode adopted by OdeMon for the recipe. • The block mode, with which is possible to send large amount of data with the smallest overload of structural data. ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  11. The ODE recipe format 190 data items 477 bytes 190 SDO expedited ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

  12. Improving the configurationspeed After some simplecalculationsabout the overloadsof the variousCANopenmodes, I obtain the followingtable: Conclusions To obtain a good improvements, I can choose the segmented SDO mode. As a consequence I should rewrite the function fwConfigurationDB_applyRecipe() and modify the recipe format (changing also all the hundred of recipes currently in use). If were possible to have the Block Mode, well implemented into the OPC-server, I could get the maximum result . . . ECS 2.0 - MUON Meeting - Roma1 - 16/10/2012

More Related