Make picomotor current position data streams 64-bit

[ivalaginja]

Bug found while working on capsule.

Python's int() function returns a 64-bit integer on the capsule Linux machine, which trips up the service when it gets fed into a data stream that expects a 32-bit integer. This PR forces it to 32-bit upon submission into said data stream.

Tested on hardware and works.

[ivalaginja]

@ehpor thinking about it, does it make a difference if I force the data stream to be created for 64-bit integers, or if I force all integers on that data stream to be 32-bit? Any general thoughts that would motivate one or the other?

[ehpor]

@ivalaginja I don't remember why I used 32-bit numbers. Maybe to limit the maximum number of steps? I see nothing in the code that signifies that the hardware needs an explicit cap at 32 bit. So making the data stream 64bit would be my solution, if you can test that on hardware first.

[ivalaginja]

@ehpor tested on the Linux machine with 64-bit and this works.

[RemiSoummer]

Tested on HiCAT hardware and works well, including sending a float giving a ValueError and not crashing.

[RemiSoummer]

all good and tested

[raphaelpclt]

I'm just seeing this now, and just as a sidenote while looking at #232. We did enforce integer casting in the proxy as well because picomotors fail if we don't cast the integers into integers (yes - twice). So even if it's working, it's now more of a code style discrepancy since int32 are used there

catkit2/catkit2/testbed/proxies/newport_picomotor.py

Line 19 in d73ad0b

new_position = np.int32(current_position + distance)

[ivalaginja]

I'm just seeing this now, and just as a sidenote while looking at #232. We did enforce integer casting in the proxy as well because picomotors fail if we don't cast the integers into integers (yes - twice). So even if it's working, it's now more of a code style discrepancy since int32 are used there

catkit2/catkit2/testbed/proxies/newport_picomotor.py

Line 19 in d73ad0b

new_position = np.int32(current_position + distance)

Oh, you're right! I also just realized that I never adjusted the int type for the current position data stream in the simulated service.
I opened #443 to fix this. Do you think you could review that @raphaelpclt?