LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Double to Hexadecimal numeric conversion and byte shift

Solved!
Go to solution

 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?

 

Pan control.png

 

Any opinion given is worthy of respect

0 Kudos
Message 1 of 7
(236 Views)

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).

Screen Shot 2022-08-10 at 12.06.14 PM.png

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 2 of 7
(217 Views)
Solution
Accepted by topic author constructionworker

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:

 

altenbach_0-1660153056857.png

 

 


@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.... 😄

0 Kudos
Message 3 of 7
(180 Views)

@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:

 

altenbach_0-1660153056857.png

 

 


@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.  


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 7
(168 Views)

@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:

 

altenbach_0-1660153056857.png

 

 


@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?

0 Kudos
Message 5 of 7
(139 Views)

@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:

 

altenbach_0-1660153056857.png

 

 


@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?


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.


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 7
(125 Views)

Thank you everyone for your answers.
I think I got the necessary answers.

0 Kudos
Message 7 of 7
(101 Views)