08-10-2022 10:29 AM - edited 08-10-2022 10:32 AM
Pan position is given in hundredths of a degree and has a range from 0 to 35999 (decimal). The value to set pan 90 degrees should be 9000.
Based on this information I created an example as below. Everything seems to be working fine.
Any given degree is sent as hexadecimal in 2 bytes.
But I want to know if there is any other way to do this than this.
Another question is is there a way to send both the pan and tilt position simultaneously (in one message) for the Pelco-d ?
Has anyone dealt with this before?
Any opinion given is worthy of respect
Solved! Go to Solution.
08-10-2022 11:08 AM
Your pic shows a lot of other things, but here is the part you asked about:
Multiply by 100 to get the integer number of hundredths.
Convert to U16 (0..65535)
Split into two bytes
Form array (append/prepend your other command bytes here).
Blog for (mostly LabVIEW) programmers: Tips And Tricks
08-10-2022 12:38 PM - edited 08-10-2022 12:40 PM
You already got a good answer.
Here's seemingly equivalent, but arguably simpler code:
@constructionworker wrote:
Another question is is there a way to send both the pan and tilt position simultaneously (in one message) for the Pelco-d ?
Well, check the manual.... 😄
08-10-2022 01:43 PM
@altenbach wrote:
You already got a good answer.
- As of your array operations, they are pure Rube Goldberg, lost of unnecessary code for the given functionality.
- You have a wild mix of representations.
- If the input range for the DBL is 0...359.99, you can set that in the control. (If the value comes from a connector, you should coerce instead)
Here's seemingly equivalent, but arguably simpler code:
@constructionworker wrote:
Another question is is there a way to send both the pan and tilt position simultaneously (in one message) for the Pelco-d ?
Well, check the manual.... 😄
Since I wrote the automated tests for those devices I can state with confidence that driving the pan and tilt motors simultaneously is technically possible (some hacking at a hardware level is needed) but you will likely overload the device. The command protocol will not act on both pan and tilt commands together.
08-10-2022 03:25 PM
@JÞB wrote:
@altenbach wrote:
You already got a good answer.
- As of your array operations, they are pure Rube Goldberg, lost of unnecessary code for the given functionality.
- You have a wild mix of representations.
- If the input range for the DBL is 0...359.99, you can set that in the control. (If the value comes from a connector, you should coerce instead)
Here's seemingly equivalent, but arguably simpler code:
@constructionworker wrote:
Another question is is there a way to send both the pan and tilt position simultaneously (in one message) for the Pelco-d ?
Well, check the manual.... 😄
Since I wrote the automated tests for those devices I can state with confidence that driving the pan and tilt motors simultaneously is technically possible (some hacking at a hardware level is needed) but you will likely overload the device. The command protocol will not act on both pan and tilt commands together.
Yes.. I was guessing I was exaggerating a bit 🙂 Thanks for your replies.
-Where is it to be hacked?
Technically 2 independent motors of course.
But I think there is a programmatic obstacle.
Earlier when I wanted to do this with the sdk provided over ethernet it couldn't be done.
I think the same is true for RS-485.
If pan and tilt are to be moved, first the pan and then the tilt should move.
when you try to do both together, the pan-tilt starts to flicker and moves slowly. In the second case, if the command is to be sent, the command cannot be sent continuously. It only allows sending with a button. It prevents the position refresh in a short time. I think there is no way to solve this either.If there is, I don't know.
If there is a solution, I would love to know.
-What is the probability of hacking the device. Are you talking about hacking the ''ARM
proccessor'' used?
08-10-2022 04:56 PM - edited 08-10-2022 05:07 PM
@constructionworker wrote:
@JÞB wrote:
@altenbach wrote:
You already got a good answer.
- As of your array operations, they are pure Rube Goldberg, lost of unnecessary code for the given functionality.
- You have a wild mix of representations.
- If the input range for the DBL is 0...359.99, you can set that in the control. (If the value comes from a connector, you should coerce instead)
Here's seemingly equivalent, but arguably simpler code:
@constructionworker wrote:
Another question is is there a way to send both the pan and tilt position simultaneously (in one message) for the Pelco-d ?
Well, check the manual.... 😄
Since I wrote the automated tests for those devices I can state with confidence that driving the pan and tilt motors simultaneously is technically possible (some hacking at a hardware level is needed) but you will likely overload the device. The command protocol will not act on both pan and tilt commands together.
Yes.. I was guessing I was exaggerating a bit 🙂 Thanks for your replies.
-Where is it to be hacked?
Technically 2 independent motors of course.But I think there is a programmatic obstacle.
Earlier when I wanted to do this with the sdk provided over ethernet it couldn't be done.
I think the same is true for RS-485.
If pan and tilt are to be moved, first the pan and then the tilt should move.
when you try to do both together, the pan-tilt starts to flicker and moves slowly. In the second case, if the command is to be sent, the command cannot be sent continuously. It only allows sending with a button. It prevents the position refresh in a short time. I think there is no way to solve this either.If there is, I don't know.If there is a solution, I would love to know.
-What is the probability of hacking the device. Are you talking about hacking the ''ARMproccessor'' used?
You could try to hack at the ARM code but it won't work well. Hacking the Hardware would require reworking the outputs to the motor drivers and results in device overload. Essentially the on-board supply cannot power both motor drive quadrature outputs. They were never intended to operate together. Frankly, I remember that much from a long time ago because the dang things were so futzing noisy that direction of the outputs were a beast to resolve. [In fact, the previous test systems mine replaced often produced GOOD devices that only panned CCW or CW]
I never worked for Pelco myself but did visit to commission the test sets and software. The Shock, vibration and noise from the Hornets taking off on full afterburner directly overhead at an altitude you could spit at, caused some unexpected results too.. My notes and dwgs were left in an old employers desk over a decade ago.
08-11-2022 12:42 AM
Thank you everyone for your answers.
I think I got the necessary answers.