A bench prototype that runs is not the same thing as a product a customer can rely on. Before equipment goes to market, its performance, safety behaviour, durability and producibility all have to be proven. That is the job of electrical control system development testing. The work is defined before a single wire is terminated, because a test plan built late only records failures instead of preventing them.
The scope on this site is deliberately broad: complete engineering support from mechanical structure and electrical control to overall system integration, with product development services covering product requirement analysis, electrical schematic diagrams, PLC control, HMI human machine interface, integration of sensors and actuators, electrical cabinet design, and safety control logic. Those same blocks decide what data a test programme has to produce.
Write the requirement list before the control panel is drawn
Requirement confirmation and solution design come first, and the output that testing depends on is a written list of measurable behaviour: what the machine must do, in which order, under which supply and ambient conditions, and what it must do when a sensor, a switch or a interlock is lost. If that list is vague, the test report becomes an opinion.
The requirement document should also fix the machine's own operating envelope. For example, the parameters published for the Fixed Steam Cleaning Machine PowerDe HW02 include a 220 V working voltage, 6 kW heating power, 160 °C steam temperature and 0.8 MPa vapour pressure, with an 80 L SUS304 tank and dry steam, wet steam and vacuum functions. Those four numbers become four measurement channels, and the protection items named on that page — leakage, short-circuit, high-temperature, high-voltage, water-shortage and high-voltage-explosion protection — become a fault-injection checklist. On the mobile side, the Driving Style Steam Cleaner PowerDe PWD02 is listed in a battery version and a version without battery, so the same functional test has to run against two different power architectures and record which one passed.
Data to capture on the electrical side
- Actual measured values at the terminals: working voltage, current per circuit, and heating or drive power in steady state and at switch-on. Recorded against the rated value, not assumed from the nameplate.
- Cabinet and wiring condition: earliness of earth continuity, protective device operation, and the temperature of conductors, terminals and the cabinet itself during a long run at full load.
- Sensor and actuator behaviour: input range, dead band, response delay and the direction of fail-safe when the signal is disconnected.
- Control logic evidence: every PLC state transition, permitted sequence, rejected sequence, and the exact condition that moves the machine between states.
- HMI records: displayed value versus measured value, alarm text, alarm history, and who was able to change a parameter.
- Protection events: the trigger, the reaction time, and the restart path for each protection item that the specification claims.
- For battery-powered variants: charge behaviour, protection behaviour at low and high state of charge, endurance on a full cycle, and the voltage and temperature trace during a duty cycle that reflects real use.
Process data and safety evidence belong in the same file
Control quality is judged on the process variable, not on the program. For a steam machine that means steam temperature and vapour pressure versus time, heating power drawn to hold them, tank level, and the difference between dry-steam and wet-steam operation. For a bonding or laminating cell it means press pressure, plate temperature, vacuum level, fitting accuracy and cycle time, which is exactly the kind of figure the equipment pages on this site quote — fitting error, working temperature, vacuum level and cycle time — and those values are what the test must reproduce rather than restate.
Safety data has to be traceable to a test event: interlock actuation and the resulting stop, emergency-stop behaviour from every mode, behaviour after a power interruption, and what the machine does when water, feed or material runs out. Where the site describes an application such as medical equipment steam cleaning on the hand-pushed HMW3 page, that context raises the documentation bar: cleaning and disinfection duty has to be demonstrated on the machine, and the operating record has to be reproducible.
How the test programme should be organised
PowerDe's published sequence for this work is requirement confirmation, solution design, engineering design, prototype manufacturing, test verification, optimization and iteration, and production import. Test verification sits between a built prototype and a production decision, and it is the gate where data either clears the design or returns it to engineering design. Two practical rules make that gate usable:
- Log continuously, do not spot-read. Duration, load profile and interruptions are part of the result, so a single end-of-run reading cannot show a thermal rise or a control oscillation.
- Every failure carries the same evidence as a pass: configuration and firmware or program version, settings, ambient conditions, instrument used, and the raw trace. Without it, an iteration cannot be compared with the run it replaced.
Deliverables that carry the data forward
The engineering design step already lists the documents that should absorb the measured data: 2D machining drawings and 3D models, electrical schematic diagrams, and the safety control logic. Prototype manufacturing and testing verification then produce the test report, the BOM list, assembly process documents, inspection standards, the factory testing plan and small-batch trial production support, each of which is a decision record. The practical way to close the loop is to write the accepted value from the test back into the drawing, the BOM and the inspection standard at the same time, so the production file matches the machine that passed.
The same data set serves customers as well as engineers. A buyer comparing equipment needs the measured performance envelope and protection behaviour, not marketing wording; the hardware testing services page and the product R&D accelerator page exist for projects that need that evidence produced, and Professional Industry Equipment shows the machine families the test programme is written for.
Before you submit the first test request
Three inputs decide how much of the above you get on the first pass: the requirement list with measurable acceptance values, the machine configuration under test including power supply and voltage, and the duty cycle you expect the product to survive in service. Provide those and the test plan can be written against the design; leave them out and the first prototype test becomes the requirement definition. Share your drawings, prototype status and target specification with the engineering team and the plan can be built around your product instead of a generic checklist.
