Perl probe kickstarter (PPK) - Part 2 - Package and distribute

Document created by pmatt on Feb 3, 2017
Version 1Show Document
  • View in full screen mode

Welcome to Part 2 of the Perl probe kickstarter. Now that our executable probe is running, we need to get it into the archive so it can be turned into a daemon and distributed out to robots. It is best to perfect your development and deployment strategy with a lean probe that does nothing. Once that is working, you know that any further problems were most likely caused by questionable code!

By the end of this part, we will have distributed the perfmonWindow probe to a robot via the archive, and it will be running as a daemon.


Navigate to the archive, right click and click 'New...' Fill in the fields shown, making sure that 'Name' matches your probe name. Right click the tab at the bottom and click 'Add section...'



Type the probe name into the 'Section name' field, leave 'Section type' unticked and click OK.

Right click the 'Dependencies' tab and click 'Add dependency'. The name of the dependency will be 'SDK_Perl', version '5.06' and Type 'ge'. This will ensure that SDK_Perl is deployed to the robot if it is not found during distribution.



Move onto the probe definitions tab, 'Add probe...': -



Name - Your probe name goes here

Description - Good to remind you what the probe does!

Group - In this case the group is 'Custom', as decided during the first part.

Type - 'daemon'

Timepsec - This field should be left blank. Delete anything that is pre-populated here. NB - clear this field to fix the 'Probe probeName not finished at next start time, restarting probe' alarm.

Workdir - Nimsoft probes folder followed by the group folder name. Remember the probes folder is different for 32bit/64bit.

Command - Name of the executable that we created with pp. 'perfmonWindow.exe' in this case.

Arguments - Leave blank.

Config file - Probe name followed by .cfg 'perfmonWindow.cfg' in this case.

Log file - Probe name followed by .cfg 'perfmonWindow.log' in this case.

Security - 'admin' This could probably be reduced to a lower setting if security is a concern. Need to do a bit of research on this, or comments welcome

Start after - Leave blank

Active - Yes

Preserve earlier Active state - Ticked


Next we need to add some files to the probe, but the .cfg file must have an extension rename before proceeding. Failure to do this will cause the remote probe's .cfg file to be overwritten every time the probe is deployed. So in this case, 'perfmonWindow.cfg' was copied to 'permonWindow.cfx' in the 'perfmonWindow_dev' directory. Click the 'Files' tab and the right click 'Add file...' Browse to each file and click OK.



Your 'Files', 'Probe definitions' and 'Dependencies' tabs should now look something like this: -




Click 'Ok' and you are all set to distribute. You can drop this package onto any robot, but I recommend you drop it onto the robot you have been developing on. Make sure you have no instances of your probe executable running in a command window, or they will clash with the daemonised probe process.



You should have the following in your probe folder. Note that we now have 'perfmonWindow' and 'perfmonWindow_dev' folders. This is basically your production and dev environments respectively. Just make sure they do not run at the same time. If you want to run your development probe by hand from the command window, make sure the probe is deactivated. If you want to run in production, make sure no command windows with running probes are open.



Now you can finally see your wonderful new probe running happily! Right click to 'View Log...' and you should see the same log output that we viewed in Part 1.



Now what you have all been waiting for in part 3! Will we add some code to send an alarm when a perf counter value falls between two thresholds.

3 people found this helpful