Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add 'W' write_to_robot cmd, resolve compiler warnings.
Implemented write_to_robot as per: https://github.com/HaddingtonDynamics/Dexter/wiki/write-to-robot My test job at this point is just new Job({name: "my_job", do_list: [Dexter.write_to_robot("THis is a test", "/srv/samba/share/test.txt") ]}) But to test the individual subcommands, I did: new Job({name: "my_job", do_list: [make_ins("W", "f", 0, "/srv/samba/share/test.txt"), make_ins("W", "s", 9, "Line one\n"), make_ins("W", "m", 9, "Line two\n"), make_ins("W", "e", 9, "Last line") ]}) I haven't tested with files longer than the size of the buffer, or which have nulls in them. Buffer size: The buffer in Dexter is 255 bytes. No single command can transfer more than that. But each sub command has overhead, so you can't transfer 255 bytes each time. And the overhead changes... If you transfer less than 10 bytes, I believe the actual string is "W ,e ,9 ,data data" for 9 bytes of overhead (from the W to the , before the "data"). If you transfer 10 to 99 bytes, it's 10 bytes because length is now 2 digits. 100 to 999 bytes; 11 overhead. We would never try to send more than 255, so at most there is 11 bytes overhead. So I think we can send 244 bytes at a time. So, let max_content_chars = 252 needs to be changed to let max_content_chars = 244 at https://github.com/cfry/dde/blob/master/robot.js#L1479 And then we can test sending larger files. Minor changes to reduce the number of warnings displayed by the compiler: #define MAX_PARAMS 26 needs to be 28 as there are actually 2 more initial values for that array. I think gcc again corrected for that in loading the array, but the value is still wrong. I changed it to 28. It should probably be defined as #define MAX_PARAMS sizeof(Params) but since it's an array of arrays it isn't worth the work to ensure the correct fix. Because MAX_PARAMS is used to index the array in SetParams called by the 'S' command in DDE, the last two parameters would not be set. That would be "EndSpeed" and "End". Not sure if that is important, but DDE does use the set_parameter command. If someone was having a problem with something that uses EndSpeed or End, that was why. In FindIndex AvgCOS and AvgSIN are never initialized. Since they are accumulated, any random garbage in memory would cause the average to be incorrect. I've added =0 to each in their definitions. It may be that gcc initializes variable to 0 by default even when it wasn't told to? Or we have been getting lucky and those memory addresses were always zero? The 'l' command from DDE would trigger LOAD_TABLES which actually calls SaveTables which writes HiMem.txt in the share but also write memText.txt (somewhere, not sure). The problem is it casts the CalTables[i] value as an integer pointer before it writes it. The subscript operation, [i], already converts the pointer to an integer so that is writing garbage. I don't think that file ever gets used again, so this probably doesn't matter. Can we just comment out the part where memText.txt gets written? To be clear HiMem.txt is NOT a problem, memText.txt is and I don't think it's used. The 'i' command from DDE would trigger CAPTURE_POINTS_CMD which ends up calling CapturePoints which then writes data out to a series of numbered files. The file number comes from EmbedRec which starts at 1 and get incremented. It's an integer, so must be converted to a string to be part of the file name. A temp string pointer, tmpSt is copied into the RecordFilename value which is being constructed, but tmpSt is never initialized. It looks like the previous line: asprintf(&tmpSt, "%d", EmbedRec++); was commented out. asprintf would work, but doesn't seem to be available. But allocating heap memory for the buffer it fills is inefficient and not needed for this application since it's just a sequence number. I've changed it to snprintf(tmpSt, sizeof(tmpSt), "%d", EmbedRec++); which will ensure no buffer overrun and defined tmpSt as char tmpSt[(8 * sizeof(EmbedRec) / 3) + 3]; //safe bet for the number of decimal digits so there is no need for a malloc or free. I don't think this code ever gets used? In setDefaults there is a line: fgets(RemoteRobotAdd, sizeof(RemoteRobotAdd)+1, RemoteRobotAddress); which will cause a zero to be written to whatever variable was in memory after RemoteRobotAdd if the data in the file were more than 255 characters. http://www.cplusplus.com/reference/cstdio/fgets/ "A terminating null character is automatically appended after the characters copied to str. " I have no idea why that +1 would need to be there... It's just reading an IP address. I've removed it. Would probably never cause a crash as the file would never have more than an IP address as a string in it. In CvrtBoundary_CenterMag_to_HILOW there is a serious pointer error, but since that function never gets called, I just corrected the error and commented out the routine. StartClientSocket is supposed to always return a value, but it only tries to return 1 if it fails. Changed to just return NULL at the end and return a pointer to char array error msg in other cases. Should work, but nothing will process the return value since the threads aren't joined. Any return is a failure... it should never return. But pthread_create expects a return value. http://man7.org/linux/man-pages/man3/pthread_create.3.html Just changed StartServerSocket StartServerSocketDDE to be of type void * so there is no warning. If they ever do return, I'm not sure what will happen since they return nothing. Several functions are called before their definition. I added a function prototype section. Not sure if that's 100% necessary with gcc... e.g. it may be smart enough to figure it out. getInput signed_angle need a return 0 at the end so if none of the other returns are hit, it still returns a defined value. SaveTables moverobotPID ProcessServerReceiveData ProcessServerReceiveDataDDE should be type void because it doesn't return anything and each time it's called, there is no expectation of a return value. CvrtBoundary_HILOW_to_CenterMag is never called. commented out. In ParseInput *p20 is never used, I removed it. In J_angles_to_xyz P20 is never used, removed. There are so many of these that I just started ignoring those warnings. They don't do any harm other than wasting some memory. In the end, I'm glad I looked at these because I had accidentally typed "close(wfp)" instead of "fclose(wfp)" which would have been interesting... https://stackoverflow.com/questions/19564797/difference-between-fclose-and-close The remaining warnings have to do with parameters sent to fread which I'm /sure/ ARE working already so I'm not sure what to do with those. e.g. DexRun.c: In function 'RestoreCalTables': DexRun.c:3421:3: warning: passing argument 1 of 'fread' discards 'const' qualifier from pointer target type [enabled by default] that line is: if((readSize=fread((const void *)CalTables,sizeof(int),4*1024*1024,fp))==(Length/4)) I honestly have no idea what the issue is there and I'm afraid to make a change.
- Loading branch information
1 parent
fb8584f
commit ef39cfe