Pelco Developer Network (PDN)

Pelco API w/ Delphi 2010 issue

WSDL files imported not working properly

I am upgrading a legacy app written in Delphi 2010 that currently uses Axis cameras only to support Pelco. I have imported the WSDL files needed for the current feature I'm working on, which is PTZ support.

I am getting a proper instance of ScriptControlPortType when I call GetScriptControlPortType from the generated ScriptControlV1 unit, but the call to ExecuteScript is failing.

I am passing it a proper string that represents the script name, but it generates an exception, saying that the result is HTML when it should be XML. Best I can figure is this in fact a webpage that describes an error, however I don't have a way to look at it. The function for ExecuteScript is such:

function ExecuteScript(const scriptName: string): Integer; stdcall;

So it doesn't return anything but a number which the value isn't indicating anything about what is actually wrong. Doesn't help that I don't really know what any error codes are, I can't seem to find any documentation on them beyond that the integer represents a boolean that indicates success or failure.

Anyone have any clues on how to get further into this?


In your post you mention that this is an older development that is using Delphi with Pelco Axis model cameras. What camera specifically is this problem occurring with? Does it occur with multiple models? If so, which ones? Also, which firmware versions are they running?

The reason I am asking these questions is to try and rule out the possibility of a specific camera issue problem that is in turn causing your requests to fail. What you are describing is odd behavior.

Another suggestion would be to use Wireshark to investigate the network traffic and look at the request to the camera and the response from the camera. Take a look at the request to see if everything looks in order, and then check what the camera's response is.

Sorry for the slow response, hadn't gotten back to this development project for a few days.

The two cameras in question are a small PTZ dome camera, IP Camera-IMP319-1ER-T51102835, and the second is a fixed camera, IP Camera - D5230-ADWTC71.

The dome is running firmware 03.29.59, I am not positive on the second, it's coming up with a 404 error when I browse the sys_information.html page, however the jpeg\ page does work.

On the PTZ dome, is that enough info to go by? Is it old?


No problem; we often do not receive a reply after advising over here, so no worries. We generally have to assume the problem is resolved unless we hear back :).

I think we might have the models and their PTZ-capabilities switched ... the IMP319 is a fixed dome camera that doesn't have PTZ capabilities (here is the Spec sheet for the IMP319 from On the final page of the spec sheet you'll see the IMP319-BASE is a fixed 3 MP camera. It is a dome in shape and size, but doesn't have motors to perform PTZ.

The PTZ camera is the D5230; this is a Spectra HD 30x zoom PTZ camera (here is the spec sheet for the D5230). On the final page of the Spec sheet you'll see that the D5230 is the dome drive spec for the Spectra HD. You'll also notice on the first page of this spec sheet that it specifically says it is a PTZ camera.

The Sarix Professional model PTZ camera is usually the P1220 these days, with the page on for those here: Sarix Professional PTZ.

Because the Spectra HD PTZ camera is coming up with errors on some of the pages, I have a concern that it is operating properly 100%. Some services might be off or not responding correctly, causing other problems all around. The camera is older, with manuals on being posted as far back as 2014, but it isn't as old as I was afraid it might be.

I would strongly encourage you to reach out to Pelco Product Support for assistance on the camera. They can help out and might request some camera logs or resets to get it to behave properly as you'd expect.


Oh! I did forget to mention that there might be differences in operation between the API services on the Axis cameras and the more recent Sarix-based models. Since the original development was done in Delphi, I presume it would have used direct requests to the camera's services for PositioningControl, LensControl (for zoom), and ScriptControl (for any presets / patterns). The service names are still the same with Sarix-based PTZ models, but some of the requests and headers for the API calls themselves might be different than what was originally implemented. That might be something else to investigate, too.

In other words, the API services are still the same, but some of the other bits between AXIS and Sarix cameras in the nuances of the requests to the camera may be slightly different. The Ports would be different: Sarix Ports, for one point. There is a troubleshooting page here for Sarix too: Sarix Troubleshooting (perhaps closed authentication? though that would give a 403 forbidden or something similar in reply). And finally there is a general Sarix page here on PDN to get started with many links there too - Sarix PDN Product Page.

Hopefully this info also is helpful!

Different headers

Your mention of the requests and headers for API calls being different is interesting, as I had noticed that. When I pull up the C++ example, a function I am using has different parameters in the C++ example than the imported WSDL file translates for me when imported into Delphi. I was thinking that maybe my WSDL files were old, but they were pulled directly from the Pelco site.

I'll look more into that and see if I can't find the exact function and list both calls here.

I think looking into them more is a good plan.

I may have suggested it before, but just in case I did not it is worth mentioning again; I strongly recommend using Wireshark and a tool like Soap UI to make the requests using the WSDL themselves to the cameras themselves (eliminating the code element) as a starting point. From there you'll be able to see what parameters are necessary for requests to receive valid responses and then use that information for the code.

Thanks for the update and good luck!

Hello there!

I received word that you are once again working on this. Please let us know if you are still having problems making the requests to the cameras. If you are, please indicate the model of the camera that you are trying to perform PTZ requests to, and what firmware version the camera(s) are running.

As a test, you may be able to try this; (1) navigate to this URL: [camera_ip/Device.xml], (2) if you receive a list of XML, locate the "PositioningControl" service. If you do not see that service in the list of running services, then the camera either isn't PTZ or isn't running the service for some reason. The latter would indicate a camera issue of some kind.

I am not actively working on this as the Pelco camera we had on loan had to be returned. I'd loved to get back into this, though, just don't have current Pelco access.

I am attempting to convince the company to allow a re-write of the software from Delphi to C#, in which I think supporting Pelco cameras will be easier, just not sure where that sits yet.

Gotcha, thank you very much for your update.

If equipment is a challenge, we do have a Partner lab that is VPN accessible with Pelco VMS and cameras on it specifically for developers (at least we do today, that may change in the coming months). If the project does end up allowing for development effort and time, please reach out to our Technology Leaders and/or Sales and we can set you up with access to that if need be.

Thanks again!

Camera access

Who specifically do I contact for that? I'd like to get the ball rolling on that, seeing a Pelco camera working in the software could sway the purchase of development time.

I could email them to you, however your address for your profile on here doesn't appear valid (the "" address).

You could reach out to our Technology Leaders (Business Development), who are named here: Partner First, and include an email address. Typically one of them will let me know and I send them the credentials that are then sent to the end users -- to you in this case.

In all honestly I must indicate that we have a major building move coming in September, and our lab will be inaccessible during that time. We may or may not have the space to keep it up and running, so for now I can only say that the lab is available from now until mid-September or so.