hex returns a string, I'm pretty sure you don't have to do that with bytearray if you've already got everything as ints.
Ha, yes, I learnt that in the live interpreter! If such is the case, my life will be many times easier.
Slight problem here. I believe that the tokenizer has tokenized the data, but when it reaches the calculator, all that can be seen is an empty string. The GIF below shows it.


This other GIF shows the computer side of things


Note that they are not in sync.

Any ideas as to why this might be happening?
What is the sequence of bytes that you are sending to the calculator to store in its string?
0x44 for type
0x44 for seq
The content is: Pause X+3 ^ 2 (Which in hex is: 0xD8, 0x58, 0x70, 0x33, 0x29, 0xF0, 0x29, 0x32)
BUMP!

Any ideas?
What target address are you using? The broadcast address, the address your calculator connects with, or something else? If the address your calculator uses to connect, how does that process work? Is your program sending anything?
UPDATE
It would appear that Wolfram has been watching this project! I got a message from a member of the Wolfram team through Cemetech personal messages. We swapped contact details and he asked if we could do a skype call. So I did!

He asked me about the progress of the project, discussed with me about the API call system and whether I needed any extra calls.

Overall, it was very informative and exciting!
That's really cool! In my experience with the API, there are two things I'd like to see--however, they're not directly related to the API, rather their web front-end:
1) If I'm logged in to W|A proper, I shouldn't have to re-log-in to the API site
2) A list of all API calls made. It keeps track of the number, it would be cool to be able to dig through and see what was actually done and when. Even as, say, a weekly export or something.
Kerm:
This is the code I use to send to the calculator:

Code:
outtoclient(0x44,0x44,titokens.tokenize("Pause X+3 ^ 2"),calc5)
ElectronicsGeek wrote:
UPDATE
It would appear that Wolfram has been watching this project! I got a message from a member of the Wolfram team through Cemetech personal messages. We swapped contact details and he asked if we could do a skype call. So I did!

He asked me about the progress of the project, discussed with me about the API call system and whether I needed any extra calls.

Overall, it was very informative and exciting!
That's awesome! Now I'm going to have even more trouble preventing myself from swooping in and throwing code at you. Wink Would you mind sending me the current computer and calculator code so I can experiment during HCWP tomorrow?
I don't see why not. Beware, though, it's a bit of an uncommented mess! And the tokenizer only does single byte characters!

KermMartian wrote:
Now I'm going to have even more trouble preventing myself from swooping in and throwing code at you. Wink


Please refrain Smile - It's better that I learn!
ElectronicsGeek wrote:
UPDATE
It would appear that Wolfram has been watching this project! I got a message from a member of the Wolfram team through Cemetech personal messages. We swapped contact details and he asked if we could do a skype call. So I did!

He asked me about the progress of the project, discussed with me about the API call system and whether I needed any extra calls.

Overall, it was very informative and exciting!


Very cool =) We showed you off to Mr. Wolfram himself at Maker Faire last fall.
E-Geek wrote:
UPDATE
It would appear that Wolfram has been watching this project! I got a message from a member of the Wolfram team through Cemetech personal messages. We swapped contact details and he asked if we could do a skype call. So I did!

He asked me about the progress of the project, discussed with me about the API call system and whether I needed any extra calls.

Overall, it was very informative and exciting!

It seems to me that Cemetech is moving ever closer to a premier website where the higher ups feel comfortable in checking on the happenings here. Great job on this, EGeek!
[Update!]

After some extensive testing with Kerm, we've found that the issues I have been having are less likely to reside in the tokenizer, but perhaps more likely in either transmission or the DCSB Libs CALCnet methods (cheifly sum( 18 )).

As described a few posts ago, the server appears to send data to the client, but when the calculator recieves data, it acknowledges that data has been recieved, yet returns an empty (11 bytes long) string. The aforementioned string is stored in Str9.

The tokenizer seems to return a list of correct bytes and we know that from client and server verbose that data is being sent and recieved, which has led us to think that sum(18 could be the offending factor.
So that bugs probably my fault. I have a special packet format that is encapsulated inside the Cn2 frame. Sadly off hand I don't remember what it is exactly. I remember a few things tho so I'll write them up real fast and I can get a definite answer for you tonight.

The packet contains a byte that specifies the type of data following that is the variable data in Ti format. So it's the raw data section of either the list or the string.

Note that's just off memory and may be wrong but I'm pretty sure that is how I did it. So I could expand it and make it handle more variables later efficiently.



(minor grammar edits whoops)
geekboy1011 wrote:
So that bugs probably fault I have a special packet format that is encapsulated inside the Calc net frame. Sadly off hand I don't remember what it is exactly. I remember a few things tho so I'll write them up real fast and I can get a definite answer for you tonight.
Informed by these pointers, I've taken a look through the DCSB Libs source code and come up with the following.
  • The arguments to Cn2Send are det(17,ID,data), where ID is a real variable like θ, and data is a string or a list.
  • The first byte of each frame Cn2Send sends is 0x01 (list) or 0x04 (string). If you construct your own frames, you must add that value as the first byte.
  • The size of the list/string is not encoded in the packet, as the frame size tells you the size of the variable. Therefore, follow the 0x01 or 0x04 directly with the data.
  • The DCS wiki correctly documents det(1Cool as taking no extra arguments, because whether you should get a list or a string is encoded in the Cn2 frame.
Progress (of sorts, anyway)!

The calculator definitely seems to be receiving data when I invoke:

Code:
outtoclient(0x04,0,titokens.tokenize("Pause X+3"),calc5


However, on the calc, it seems to appear that Str9 is 55307 bytes large.

Here's the verbose from CALCnet client:

Code:
Wrote 14 bytes to socket (join msg)
Received 19 bytes
00 00 00 00 00 0A 3E 6C FFFFFFA3 53 07 00 04 04 00 50 49 4E 47
|0A3E6CA353.0000000000,0700:04040050494E47>Sending calc ID 0A3E6CA353 to server
Wrote 13 bytes to socket (connect msg)

              > l   S             P I N G  Broadcasting data of length 7 to server
Wrote 25 bytes to socket (broadcast msg)

Received message of length 24 from server.
FF89 0A3E6CA353 AAAAAAAAAA 0600 0400D8587033 2A
       > l   S                        X p 3  *
Wrote frame, type 'f', size '21', to bridge


Any ideas?
I spy an extra $00 in there that doesn't belong, because you're using a different packet format from the one outtoclient() originally expected. Change outtoclient() as follows and try again (although I doubt this will fix that "massive" string):
Quote:
def outtoclient(type,seq,contents,sid):
gcnlock.acquire()
msgindex = 0;
thisoutmsg = chr(type) + chr(seq) + contents
I've removed all of that.

Just ran the code again. Str9 now clocks in at a slightly lighter 22755 bytes.

Just out of curiosity, what was "seq" for?
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 5 of 6
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement