All TCP does is bypass the loading and saving of the data in a CSV file as a middle-man

The advantage to having a CSV file is that there's extra layer of redundancy for data loss. Also, a CSV file can be manually edited for quick tweaks - or combined with other CSV files to create a longer animation.

With TCP, the data would move directly from the animation software into ARC's plugin. If it's TCP, i would recommend a simple packet format such as..

0x45 // header
0x5A // header
uint32 TIMESTAMP_MS
byte BOARD_INDEX
char[3] PORT_NAME // i.e. D0, D2, V2, etc
uint16 DEGREES // I'd make this 16 bit so it can accommodate higher precision servos

I see the benefits of both now, will relay this copy+pasta style.

Also note that if the desired communication into ARC is via TCP, that the ARC skill plugin can also be responsible for saving a CSV. So that's possible as well...

Downside to TCP is that ARC would need to always be running, the robot project loaded... And if you want the robot to move in realtime, it'll have to be connected to a robot (but that's optional)

Quote:

Guy I hired is expert at max script, C++ and C# with electronics experience

I got the files, so reading your last posts I am right about that those scenes do not relate to the Max Script examples that you postet earlier on right?

What you send me is a soild mechanical rig, I will use this to show how I extract rotational values by stiing everything up for the base object and this way you can also get the rotations for all the other joints...But I guess anyways the guy that you hired will figure it out!

@DJSures That might be the way to go...even on 30fps there is still the need to have a transition in between frames, and this might be the biggest issue! At the moment I am sending integer values and I am smoothing them out in between frames like this.

filter = 0.05; // 0.01 to 1.0 d0_sh = d0_sh * (1.0-filter) + d0 * filter;

So I can tune a smooth transition...this at times affects the movement since the next values are being send before the final position is reached, but since I know the framerate I can kind of eyeball how much filter needs to be applied!

I put a slider to the scene which reads the rotational values, the vaules are being read out from the Expose Transform Helper Object. They are connected using the Wire Parameters Dialog! Also you need to convert to to degrees, because the Expose Transform Helper extracts the rotational values in radians! Its all set up, and can be applied to all you other joins as well!

https://we.tl/c0JpSvnszv

Finding a Max Script expert is not easy lol so I used Upwork. Freelance specialist from all over the world and every discipline you can think of. We use them occasionally when we encounter a technical problem that no one on the team is trained in. It hurts me everytime because Im so cheap that if they started charging for air I'd just hold my breath but... THE WORK MUST GO ON! lol

yes, they do not relate. That was just scrabbled up bits of code from different sources trying to work out the problem. the best we had gotten to fully work was the first code I posted. Its sloppy, doesnt handle different kinds of joints and is formatted horribly but it was a start! once our programmer is done though we will have a good reliable script that will be clean and dynamic for @DJ to make a plug-in for. oh quick update for you guys, so he sent me a first run of the output data for the first ten frames and it looks good. still needs some work to format it for the plug-in and to have time stamp, a line for port at the top etc but he should be done and it should all be posted by tomorrow evening. I'll post an example of the csv file tomorrow before I finish my contract for this job with him and hopefully if @Dj is on and takes a look he can give the go ahead or corrects to make so that its format suits the needs for making this plug-in.

(
	fn writeData bn toFile =
	(
		data = if bn.parent == undefined then bn.transform.rotation as eulerAngles else (bn.transform*inverse(bn.parent.transform)).rotation as eulerAngles
		format ",%,%,%" data.x data.y data.z to:toFile
	)
	
	fn recursiveWriteData bn toFile =
	(
		format "%" bn.name to:toFile
		format ",%" (if bn.parent != undefined then bn.parent.name else undefined) to:toFile
		for t = animationRange.start to animationRange.end do
		(
			at time t
			(
				writeData bn toFile
			)
		)
		format "\n" to:toFile
		for obj in bn.children do recursiveWriteData obj toFile
	)
	
	fn getFileName =
	(
		return getSaveFileName caption:"Save..." types:"Excel(*.csv)|*.csv|"
	)
	
	fn main =
	(
		root = undefined
		if selection.count != 1 then
		(
			messageBox "Please select just the root joint and re-execute the script." title:"Error: rootJoint"
			return -1
		)
		else
		(
			root = selection[1]
		)
		fileName = getFileName()
		if fileName == undefined do
		(
			messageBox "Please select a filename for the file to be saved." title:"Error: fileName"
			return -1
		)
		file = undefined
		if doesFileExist fileName then file = openFile fileName else file = createFile filename
		recursiveWriteData root file
		
		flush file
		close file
	)
	main()
)

@mickey666maus Ah that slider is pretty cool man! looks good. Ill go ahead an forward it to him, just in case it helps him. Either way once he is done I will post the example .csv file and the code for anyone who wants to improve and expand upon it in the future to include TCP and any other feature. How would you go about converting the sliding joint? In your opinion. We took similar routes to get rotational degrees I think but my thoughts on the slider was to calculate the distance it travels in the local axis its confined to and have that placed in the csv file separately so one can apply a ratio formula that is specific to their machine to know how many degrees it takes to move 10 units of distance or something. Like I told @Dj thats roughly how you calibrate the firmware on a 3d printer and it seems like the most versatile route. what do you think? what would be your approach?

Question for whenever for @DJSures: So I'll be taking the output from your plug-in and running it through a Pi thats running windows 10 Iot Core so it can process the UWP code. My question is, because I am ignorant in the specifics of this and my engineer is busy rewriting the SPI on our stepper boards for the pi ATM, what if anything will he have to do to the UWP output that your software will produce to get it to run? What I mean is: Your platform is servo centered largely, which makes sense but I have 4 servos and more than a dozen nema's. So between having the UWP code on the Pi and executing it to the stepper driver boards do you suspect any complications my engineer will have to work around given the nature of your software platform? I don't know anything about UWP so Im sorry if this is a stupid question, my permanent excuse to you engineer types is "I'm a biologist" lol Just thought I'd ask.