F T - National Solar Observatory
TProject DocumentationDocument TN-0154Revision 1.1AFSummary of CSF Motion ControllerPerformanceErik JohanssonRSoftware GroupDMay 27, 2011Advanced Technology Solar Telescope950 N. Cherry AvenuePhone 520-318-8102atst@nso.eduhttp://atst.nso.eduTucson, AZ 85719Fax 520-318-8500
Summary of CSF Motion Controller PerformanceREVISION SUMMARY:Date:Revision:Changes:May 25, 20111.0Created2.Date:Revision:Changes:May 27, 20111.1Minor updates based on BDG’s comments.DRAFT1.TN-0154, Revision 1.1Page ii
Summary of CSF Motion Controller PerformanceTable of ContentsINTRODUCTION . 1SUMMARY OF TEST SYSTEM . 1HOST CPU . 1DELTA TAU SYSTEM . 1PERFORMANCE TESTS . 2TYPICAL MOVE TEST . 23.1.13.1.2Single Motor Test Results. 2Multiple Motor Test Results . 43.2REAL TIME MOVE TEST . 63.2.13.2.2Results Measured by the Delta Tau System . 6Results Measured by the TSync Timing Board . 84.CONCLUSIONS . 11DRAFT1.2.2.12.23.3.1TN-0154, Revision 1.1Page iii
Summary of CSF Motion Controller Performance1. INTRODUCTIONThis note describes the results of timing tests performed using the Common Services Framework Basesoftware components to control motors with a Delta Tau Power PMAC (PPMAC) system. Two basic testswere performed to measure the software overhead of performing motor moves. The first test uses themove() method of the IMotion interface, which is the typical way of commanding a motor using a CSFMotionController. The move() method sends each move command to the PPMAC as a separatetransaction. The second test uses the rtMove() method of the IAdvancedMotion interface, which is aspecialized functionality that implements a series of moves over an array of positions in real-time on thePPMAC using an external trigger for very precise and deterministic control. The details of the real-timemove are explained in more detail in Section 3.2 below.FTThe results are quite good in both cases with low latency, very small standard deviations, and no majoroutliers found in 10,000 moves. These tests were performed using the DeltaTauConnection object, whichis the software object the CSF MotionController class uses to send commands to the Delta Tau system.Hence, these results represent the performance that would be seen at an individual BaseMotionController. These results should be combined with the results of John Hubbard's CSF testing toestimate the performance of a typical Instrument Controller (see TN-0143, CSF Benchmarks).2. SUMMARY OF TEST SYSTEM2.1HOST CPUAThe test system consists of a rack mounted host CPU running the Common Services Framework (CSF)and a Delta Tau motion control system.The host computer system used for testing consists of the following:D ABMX rack-mount server with the following hardware:o Intel Xeon Quad-Core CPU, 2.4 GHzo 4GB DDR2 SDRAMo 4-port PCI 1Gb Ethernet cardo Spectracom TSync-PCIe-PTP timing boardThe following software is installed:o CentOS 5.6 operating systemo ATST Common Services Framework and Base Softwareo VMWare player 3.1.4 hosting a Windows 7 virtual CPUo DeltaTau PPMAC IDE running under Windows 7R 2.2DELTA TAU SYSTEMThe Delta Tau motion control system consists of the following: Delta Tau UMAC crate populated with the following:o Power PMAC CPU, 1 GHz, 2GB DDR2 SDRAMo ACC-24E 4-axis servo interfaceo ACC-14E TTL digital I/O cardDelta Tau 3U42 dual channel PWM servo amplifier4 Kollmorgen AKM21E-ANMN2-00 DC brushless servo motorsTN-0154, Revision 1.1Page 1 of 11
Summary of CSF Motion Controller PerformanceThe server and PPMAC are connected on a private Ethernet link using a Cat-5 crossover cable.The ACC-14E I/O is configured with ports 1-24 as unlatched inputs and ports 25-48 as outputs. TheTSync timing card is used in one of the tests to provide a signal to the ACC-14E for triggering the motormoves and also to record timestamps to measure the system performance. The specifics of theconnections between the TSync card and the Delta Tau will be discussed in the section below describingthe test.The motors were configured using the Motor Setup GUI tool in the PMAC IDE and standard auto-tuningof the commutation current loops and servo loops was performed. No optimization of the servo loops wasattempted, as the purpose of the tests is to understand the software latencies associated with commandingthe motors from CSF, not to squeeze the last drop of performance out of the motors.3. PERFORMANCE TESTS3.1FTAs described above, two types of tests were performed: the first using the typical move() method, whereeach command is sent as a separate transaction between CSF and the Delta Tau system, and a real-timetest using the rtMove() method, where arrays of positions are sent to the Delta Tau and the Delta Taumanages the control of the motor moves using an external trigger input. These tests are described in moredetail in this section.TYPICAL MOVE TESTRAThis test consisted of closing the servo loop on the motors, moving them to a pre-defined position andthen repeatedly sending commands to move to the current position (a null move). The motors wereconfigured to use the default Delta Tau jog acceleration and jerk inverse rates (motor[x].jogta -10 andmotor[x].jogts -50, in Delta Tau terminology). This allows them to complete their moves as rapidly aspossible based on acceleration as opposed to a timed move. Because they are null moves, the actual movetime is negligible, which allows for a direct measurement of the software overhead of the movecommand. Also, the move does not use an in-position test to determine that the move is complete, as thetime for the motor to be in position is a function of how well-tuned the servo loop is and how tight the inposition bound parameters are set. Instead, the move is considered complete when the Delta Tau isfinished processing the move command, which indicates the move is finished and the servo is responsiblefor maintaining the current position.DFrom the high-level software perspective, commanding a move on a motor is an inherently asynchronousprocess: the software controller executes the move command, which returns immediately upon acceptanceof the command, and then the controller must wait for confirmation that the move is complete. The movecompletion notification is accomplished using a software callback. Hence, there are two latencies to bemeasured: the command-response time and the callback-response time. The callback-response timeincludes the original command-response time as well and so represents the total software overheadrequired to move the motor and receive the callback that the move is complete. A user may choose not toregister for move completion callbacks and can improve the efficiency slightly by doing so.3.1.1Single Motor Test ResultsThe results for moving a single motor for 10,000 iterations are shown below in Table 1. Scatter plots forboth portions of the test are shown below in Figure 1 and Figure 2. The means in both cases are quitesmall with small standard deviations as well. The typical latency including callback is in the 1.5 to 2.5msec range, which is quite good.TN-0154, Revision 1.1Page 2 of 11
Summary of CSF Motion Controller ck0.7417.551.180.3751.497.552.410.504AFTTable 1: Statistics for 10,000 iterations of a null-move for a single motor. Times are in msec.DRFigure 1: A scatter plot showing the command-response times for 10,000 null move commands of a single motor.TN-0154, Revision 1.1Page 3 of 11
TSummary of CSF Motion Controller PerformanceFFigure 2: A scatter plot showing the callback-response times for 10,000 null move commands of a single motor.Multiple Motor Test ResultsA3.1.2DRThe results presented above are for moving a single motor. When multiple motors are used and thecommands are sent simultaneously, the main CSF Delta Tau driver queues the commands and send themone at a time to the PPMAC (the alternative is to have a separate connection to the Delta Tau for eachmotor in use, which quickly becomes unwieldy due to the large overhead associated with eachconnection). Queued commands are delayed by one or more command-response times, depending on thenumber of commands in the queue. The tests in this section were performed to assess these latencies whenmoving multiple motors. Four motors were commanded simultaneously using multiple threads and Javasynchronization methods to execute a series of 10,000 moves. At the beginning of each iteration, themotors wait until they are all ready to move. When the last motor indicates its readiness, the go commandis given and each thread issues the move command to its motor. The results are shown below in Table 2.No significant differences were seen in the statistics from motor to motor, so only the composite resultsare presented. This indicates that the overall system does not favor a particular motor when they arecommanded in this fashion. Scatter plots are shown in Figure 3 and Figure 4. The mean response timeincreased roughly by a factor of two, which is the square root of the number of motors used. However,there is insufficient data (and motors) to support this assertion for the general case. Note the striped natureof the scatter plots. This is due to the time slicing of the real-time operating system in the Delta 13.03.011.541.9314.04.391.46Table 2: Statistics for 10,000 iterations of a null-move for four motorscommanded simultaneously. Times are in msec.TN-0154, Revision 1.1Page 4 of 11
FTSummary of CSF Motion Controller PerformanceDRAFigure 3: A scatter plot showing the command-response times for10,000 null move commands of four motors commanded simultaneously.Figure 4: A scatter plot showing the callback-response times for10,000 null move commands of four motors commanded simultaneously.TN-0154, Revision 1.1Page 5 of 11
Summary of CSF Motion Controller Performance3.2REAL TIME MOVE TESTThe Real-Time Move capability is designed to accommodate applications with extremely strictdeterministic guaranteed-response times, such as the exposure cadence of the VBI. It is implemented bysending an array of positions ahead of time to the PPMAC and using a special motion program to cyclethrough the array. An external hardware pulse is used to trigger the start of each move. When the triggerpulse is received, the motion program commands the motor to move to the next position in the array. Onthe PPMAC, a separate thread is used to run the motion program for each motor. The Spectracom TSynctiming board is used to generate a square wave pulse for the trigger, which is sent to the Delta Tau ACC14E digital I/O board, where it can easily be captured by a motion program.TFor this test an array of four positions was used and each motor was moved through the four positions2500 times, for a total of 10,000 moves. Each motor was given a shifted version of the position array sothat no motor was moving to the same position as any other motor. The following position arrays wereused for motors 1 through 4, respectively: {0º, 270º, 90º, 180º}, {270º, 90º, 180º, 0º}, {90º, 180º, 0º,270º}, {180º, 0º, 270º, 90º}. A rotary move program was used that is capable of moving in both directionsand determines the shortest path to the next position (e.g., from 0º to 270º a -90º move is used). The motorparameters were set to use an acceleration S-curve of 40 msec, which programs the move to complete in160 msec. The TSync trigger square wave was programmed to have a period of 200 ms with a duty cycleof 50%, triggering on the falling edge.AFTimes were recorded using the Delta Tau and the TSync timing board. In the Delta Tau, times wererecorded at strategic points in the move program using the PPMAC sys.time function, which records thetime with nanosecond accuracy and is suitable for measuring time differences, not absolute time. Thetimes were recorded just before moving the motor (just after receiving the external trigger), and just afterthe move was completed. The times were recorded on the TSync board using timestamps when the triggerwas sent, when the trigger was received by the Delta Tau, and when the Delta Tau indicated the movewas complete. Due to hardware limitations, only the move times associated with motor 1 were recordedby the TSync, whereas the times for all four motors were recorded by the Delta Tau.DRThe TSync board has some constraints on how timestamps may be measured that influenced theconnections between the TSync and the Delta Tau. In particular, it is not possible to program the TSync torecord timestamps for both rising edges and falling edges on a single input. The Delta Tau is programmedto use a single output bit to indicate both receipt of the trigger and completion of the move. The output isnormally high, indicating move completion. When a trigger is received, the output is lowered and keptlow until the move is complete, at which point it is raised again. In order to capture both of these edgetransitions in the TSync, the Delta Tau output is routed into two separate TSync inputs: one to capture therising edge (move complete) and the other to capture the falling edge (trigger received). It is also notpossible to capture timestamps when a TSync output transition occurs. Hence, the TSync trigger output isalso routed back to another TSync input so that trigger timestamps can be recorded.3.2.1Results Measured by the Delta Tau SystemThe Real-Time Move results measured by the Delta Tau System are shown below in Table 3. Nosignificant differences were seen from motor to motor, so the composite results for all motors are shown.The interval is the time between triggers and measures the stability of the incoming trigger signal. Themove time represents the difference between the move complete timestamp and the trigger timestamp.Scatter plots showing the results for all four motors are shown in Figure 5 and Figure 6.TN-0154, Revision 1.1Page 6 of 11
Summary of CSF Motion Controller PerformanceStatisticsMinMaxMeanStdDevIntervalMove 68Table 3: Statistics for 10,000 iterations of the Real-Time move for four motorscommanded simultaneously as measured by the Delta Tau system. Times are in msec.DRAFTThese results are excellent. Note the striping in the trigger interval scatter plot, which represents thesampling of the extremely regular trigger pulse from the TSync board by the Delta Tau motion programs,which are time sliced. Note also the striping in the move time scatter plot. This is also due to the timeslicing of the Delta Tau, as each motor is commanded by a separate thread running the Real-Time moveprogram. It appears as though the threads are given time in a round-robin fashion in order by motornumber (this is the order in which the motion programs are started). The overall spread in move times isless than 0.2 msec and for each motor is less than 0.1 msec.Figure 5: A scatter plot showing the trigger interval times as measured by the Delta Tau for10,000 repetitive trigger pulses generated by the TSync timing board.TN-0154, Revision 1.1Page 7 of 11
TSummary of CSF Motion Controller PerformanceFFigure 6: A scatter plot showing the move times as measured by the Delta Tau for 10,000 repetitivemove commands of four motors commanded simultaneously using the Real-Time Move program.Results Measured by the TSync Timing BoardA3.2.2While the Delta Tau results are accurate to the drift of its internal clock, it is instructive to measure theperformance using a highly accurate timing board such as the TSync. The TSync timestamp capability isaccurate to less than 10 nsec and has much lower drift than the Delta Tau clock.DRThe Real-Time Move results measured by the TSync are shown below in Table 4. The trigger interval isthe relative time between triggers. The trigger time is the time between the trigger and the Delta Taunotification that the trigger has been received. The move time is the time between the trigger receivednotification and the move complete notification. The Move total is the time between the trigger and themove complete 0.12777107Move TimeMove 161.25197160.990830.1288741Table 4: Statistics for 10,000 iterations of the Real-Time move for four motorscommanded simultaneously as measured by the TSync timing board. Times are in msec.Scatter plots for these measurements are shown below in FiguresFigure 7,Figure 8Figure 9Figure 10.Note that the TSync measures its own trigger interval to be perfect at 200 msec for each iteration. Thetime for the Delta Tau to respond to the trigger is quite small, always less than 500 sec, indicating thelow overhead of using an external trigger with the Delta Tau. The move times are consistent with thoseTN-0154, Revision 1.1Page 8 of 11
Summary of CSF Motion Controller PerformanceFTshown above measured by the Delta Tau, and the total move times are increased only by the small amountof the external trigger overhead.DRAFigure 7: A scatter plot showing the trigger interval times as measured by the TSync for10,000 repetitive trigger pulses generated by the board itself.Figure 8: A scatter plot showing the trigger response time of the Delta Tau system for 10,000 repetitive move commands.TN-0154, Revision 1.1Page 9 of 11
TSummary of CSF Motion Controller PerformanceDRAFFigure 9: A scatter plot showing the move times as measured by the TSync for 10,000 repetitive move commandsof motor 1 when four motors are commanded simultaneously using the Real-Time Move program.Figure 10: A scatter plot showing the total times from trigger to move complete as measured by the TSyncfor 10,000 repetitive move commands of motor 1 when four motors are commanded simultaneouslyusing the Real-Time Move Program.TN-0154, Revision 1.1Page 10 of 11
Summary of CSF Motion Controller Performance4. CONCLUSIONSDRAFTThese results are quite encouraging and clearly demonstrate the ability of the CSF motion controlsoftware to perform with low overhead high repeatability. The results of the Real-Time Move tests alsodemonstrate the ability of the software to perform reliably in very strict deterministic guaranteed-responsetime environments. Both of the motion paradigms tested in this note will meet the fairly strictrequirements of the VBI exposure cadence.TN-0154, Revision 1.1Page 11 of 11
The Delta Tau motion control system consists of the following: Delta Tau UMAC crate populated with the following: o Power PMAC CPU, 1 GHz, 2GB DDR2 SDRAM o ACC-24E 4-axis servo interface o ACC-14E TTL digital I/O card Delta Tau 3U42 dual channel PWM servo amplifi
Solar Milellennium, Solar I 500 I CEC/BLM LLC Trough 3 I Ridgecrest Solar Power Project BLM 250 CEC/BLM 'C·' ' Solar 250 CEO NextEra I Trough -----Abengoa Solar, Inc. I Solar I 250 I CEC Trough -I, II, IV, VIII BLM lvanpah SEGS Solar I 400 I CECJBLM Towe'r ico Solar (Solar 1) BLM Solar I
Mohave/Harper Lake Solar Abengoa Solar Inc, LADWP San Bernardino County 250 MW Solar Trough Project Genesis NextEra Energy Riverside County 250 MW Solar Trough Beacon Solar Energy Project Beacon Solar LLC Kern County 250 MW Solar Trough Solar Millennium Ridgecrest Solar Millenn
4. Solar panel energy rating (i.e. wattage, voltage and amperage). DESIGN OF SYSTEM COMPONENTS Solar Panels 1. Solar Insolation Solar panels receive solar radiation. Solar insolation is the measure of the amount of solar radiation received and is recorded in units of kilowatt-hours per square meter per day (kWh/m2/day). Solar insolation varies .
responding to the solar direction. The solar tracker can be used for several application such as solar cells, solar day-lighting system and solar thermal arrays. The solar tracker is very useful for device that needs more sunlight for higher efficiency such as solar cell. Many of the solar panels had been
There are three types of solar cookers, solar box cookers or oven solar cookers, indirect solar cookers, and Concentrating solar cookers [2-10]. Figure 1 shows different types of solar cookers namely. A common solar box cooker consists of an insulated box with a transparent glass or plastic cover that allows solar radiation to pass through.
Biodiversity Guidance for Solar Developments BRE National Solar Centre, Eds G E Parker and L Greene (2014) Planning Guidance for the Development of Large Scale Ground Mounted Solar PV Systems BRE National Solar Centre Solar Farms: Ten Commitments UK Solar Trade Association Model Ordinances Connecticut Rooftop Solar PV Permitting Guide
To familiarize yourself with how to read magnetograms, visit the Stanford Solar Center’s Solar Magnetograms website (see Resources section). Background Information: The Solar Dynamics Observatory (SDO) was launched on February 11, 2010 from Cape Canaveral, Florida. It is the first mission
Carolina show off the 8 foot solar cooker they constructed as a class project. Solar Fountains Dynamic Demonstrations of Solar Power at Work Solar fountains are fun and easy to build. Using . Building a Solar School Yearly 10th Grade Project Adds Capacity to Midland School's Solar Array Midland School is going solar, one class at a time .
